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Description 
PAY YOURSELF FIRST BUDGETING 

Cross Reference to Related Applications 

[0001] This application is a continuation-in-part of U.S. Serial 

No. 10/010,947 filed on November 6, 2001 entitled "Sys- 
tem And Method For Networked Loyalty Program", which 
itself claims priority to U.S. Patent Application Serial No. 
09/836,213, filed April 17, 2001 and entitled "System and 
Method for Networked Loyalty Program", which claims pri- 
ority to, and the benefit of. United States Provisional 
Patent Application Serial No. 60/279,817, filed March 29, 
2001 and entitled "System and Method for Networked In- 
centive Awards Program", and U.S. Provisional Patent Ap- 
plication Serial No. 60/246,208, filed November 6, 2000 
and entitled "Virtually Complete Purchasing", which are all 
hereby incorporated by reference. This application also 
claims priority to, and the benefit of, U.S. Provisional Ap- 
plication Serial No. 60/542,716, entitled "Pay Yourself 
First System And Method" filed February 6, 2004 and U.S. 
Provisional Application Serial No. 60/552,857, entitled 



"Improved Pay Yourself First System And Method", filed 

March 11, 2004, which are both hereby incorporated by 

reference in their entirety. 
Field of Invention 

[0002] Thjg invention relates generally to money management, 

and more particularly, to the hierarchical distribution of 

income among a user's savings account and a user's debts 

and monitoring a consumer's purchasing activity based 

upon an established budget. 
Background of Invention 

[0003] An increasing number of people have difficulty managing 
their income and debts as evidenced by an increase in 
bankruptcies, home foreclosures, excessive credit card 
balances, and other money mismanagement practices. 
Additionally, a larger number of people tend to live pay- 
check to paycheck, and unfortunately, an increasing num- 
ber of consumer services take advantage of consumer's 
money mismanagement practices. For example, an in- 
creased number of financial products and services exist 
which put people in larger debt or require people to pay 
more bills including, for example, check cashing centers 
with large fees, home equity loans, interest free or pay- 



ment free purchases for a certain number of months, cash 
advance offers, pawn shops, short-term cash loans with 
large interest rates, debt consolidation loans and early 
partial monies based upon the user assigning tax rebates. 
[0004] Furthermore, due in part to the increased use of charge 
cards, payment plans, layaway plans, periodic payment 
plans, loans, mortgages and other services which are 
billed periodically, people are typically forced to manage 
numerous bills and other debts each month. Upon receiv- 
ing a bill, many people pay the bill immediately or as soon 
as possible to avoid missing a payment and to avoid any 
late fees. Many people also usually pay bills immediately 
upon receipt in fear that their credit rating may be af- 
fected, fear that they may be sued, fear of late fees, dis- 
continuance of service, a dislike of owing money, and/or a 
dislike of unresolved bills piled up in their homes. More- 
over, many people will often use all of their income to pay 
bills first, spend all of their discretionary money, then at- 
tempt to save the remainder of the income, which is often 
little or no money. As such, many people are unable to 
save a sufficient amount of money. Accordingly, a system 
is needed to encourage and increase savings prior to pay- 
ing all or a portion of debts, while reducing such bill pay- 



ment fears and at least partially discouraging the attitude 
to pay the entire amount of bills or debts first. 

[0005] Moreover, while automatic bill payment systems exist, the 
automatic bill payment systems typically require con- 
sumer input of a particular amount to be paid and a par- 
ticular bill to be paid. However, the automatic bill payment 
systems do not include any hardware or software to con- 
sider user income, user income sources and user savings 
goals when determining bill payments. Additionally, be- 
cause third party companies operate the automatic bill 
payment systems, the automatic bill payment systems 
cannot be sufficiently customized or altered to provide 
such features. Accordingly, a technical problem exists 
wherein the automatic bill payment systems lack certain 
needed features. As such, a need exists to develop com- 
plex hardware and software to analyze income sources 
and savings goals before transferring the consumer funds 
to an automatic bill payment system. 

[0006] Incentive award programs have been developed in a vari- 
ety of industries to promote customer loyalty. Generally, 
such programs reward customers for repeat business with 
the same merchant or service provider by accumulating 
reward points which can then be redeemed in a plurality 



of ways, including exclianging the reward points for addi- 
tional goods and services that may be selected from an 
approved list or a redemption catalog, for example. The 
reward points are usually calculated using a predeter- 
mined formula or ratio that relates a customer's purchase 
volume (i.e., in terms of money value or some other vol- 
ume parameter) to a certain number of reward points. For 
example, reward points may be issued on a one-for-one 
basis with each dollar that a customer spends on particu- 
lar goods and services. 
[0007] One well-known example of a customer incentive pro- 
gram is a "frequent flyer" program which rewards airlines 
passengers with "mileage points" based upon the dis- 
tances that the passengers fly with a particular airline. The 
mileage points may then be redeemed for free airfare or 
free car rentals. Other incentive award programs are de- 
signed to induce usage of particular financial instruments, 
such as credit cards or debit cards, by accumulating re- 
ward points or dollar value points based upon the volume 
of purchases made using the particular financial instru- 
ment. These types of programs may be designed such 
that customers of the financial institution accumulate re- 
ward points which can be redeemed for selected goods or 



services or, alternatively, such that customers accumulate 
points which have a dollar value which can be applied to- 
ward a credit or debit balance, depending on whether the 
instrument is a credit or debit instrument, for example. 
[0008] These and other similar incentive award programs are de- 
scribed in U.S. Patent Nos. 5,774,870 and 6,009,412, is- 
sued to Thomas W. Storey and assigned to Netcentives, 
Inc., both of which are hereby incorporated by reference 
to the extent that they describe an automated rewards 
system. For more information on loyalty systems, transac- 
tion systems, electronic commerce systems, and digital 
wallet systems, see, for example: the Shop AMEX™ system 
as disclosed in Serial No. 60/230,190 filed September 5, 
2000; the MR as Currency™ and Loyalty Rewards Systems 
as disclosed in Serial No. 60/197,296 filed on April 14, 
2000, Serial No. 60/200,492 filed April 28, 2000, and Se- 
rial No. 60/201,114 filed May 2, 2000; a digital wallet 
system as disclosed in U.S. Serial No. 09/652,899 filed 
August 31, 2000; a stored value card as disclosed in Serial 
No. 09/241,188 filed on February 1, 1999; a system for 
facilitating transactions using secondary transaction num- 
bers as disclosed in Serial No. 09/800,461 filed on March 
7, 2001; and also in related provisional applications Serial 



No. 60/187,620 filed March 7, 2000, Serial No. 
60/200,625 filed April 28, 2000, and Serial No. 
60/213,323 filed May 22, 2000; all of which are herein 
incorporated by reference. Other examples of online 
membership reward systems are disclosed in U.S. Patent 
No. 5,774,870, issued on June 30, 1998, and U.S. Patent 
No. 6,009,412, issued on December 29, 1999, both of 
which are hereby incorporated by reference. A further ex- 
ample of a loyalty and reward program may be found at 
the AIR MILES® Web site (www.airmiles.ca), which de- 
scribes a loyalty program offered by The Loyalty Group, a 
privately held division of Alliance Data Systems of Dallas, 
Texas, and which is hereby incorporated by reference. 
Additional information relating to smart card and smart 
card reader payment technology is disclosed in Serial No. 
60/232,040, filed on September 12, 2000, and U.S. Patent 
Nos. 5,742,845, 5,898,838 and 5,905,908, owned by 
Datascape; all of which are hereby incorporated by refer- 
ence. Information on point-of-sale systems and the ex- 
ploitation of point-of-sale data is disclosed in U.S. Patent 
No. 5,832,457, issued on November 3, 1998 to O'Brien et 
al., which is hereby incorporated by reference. 
[0009] Portions of each of the above-described programs may be 



used to induce customer loyalty to particular merchants or 
service providers who directly provide goods or services 
to the consumer. In other words, these prior art frequency 
awards programs provide a means for retail businesses, 
financial institutions, and others In direct contact with the 
customers they service to provide incentives to their cus- 
tomers to encourage repeat and/or volume business. 
However, these programs do not sufficiently address the 
similar needs of businesses that are further up In the dis- 
tribution chain, such as manufacturers, to promote vol- 
ume purchases by customers based upon, for example, 
brand loyalty Independent of the retail source for the pur- 
chase. Additionally, the prior art programs do not provide 
a means for monitoring, tracking, and/or analyzing con- 
sumer and product data across distribution channels for a 
particular manufacturer and/or the variety of goods which 
that manufacturer places into the stream of commerce for 
ultimate sale to consumers by a retailer. 
[0010] Generally, before a product arrives at a retail establish- 
ment for sale to a consumer, the product travels through 
a distribution chain which originates with the manufac- 
turer. The manufacturer typically sells Its products to a 
wholesaler who in turn sells those products to various re- 



tailers. Most modern retailers implement some form of 
computerization or electronic technology in their day- 
to-day operations. This technology typically consists of 
using point-of-sale (POS) systems for automating check- 
out procedures, assisting sales personnel, and the like. 
POS systems generally include one or more automated 
check-out terminals which are capable of inputting or 
sensing and interpreting a symbol or other indicia related 
to the product, such as a Universal Product Code (UPC), 
generally comprising a machine-readable bar code cou- 
pled with a human-readable UPC number, that is printed 
on a label or tag which is placed on each item of mer- 
chandise to be purchased. The manufacturer may assign 
and mark each product that it sells with a UPC. Conven- 
tionally, once the product reaches the retailer, the retailer 
further identifies each product with a Stock Keeping Unit 
(SKU) number or code as well as other information for 
identifying a specific item or style of merchandise. The re- 
tailer's SKU number may be either an entirely different 
number used to identify each product (e.g., by style) or a 
modified version of the manufacturer's UPC number, de- 
rived, perhaps, by adding a SKU number to the UPC num- 
ber, for example. 



[0011] A POS terminal, a kiosk terminal, or a sales person's 

hand-held terminal might be coupled to a store computer 
system, such as a network server or some other store 
platform host, which is able to recognize and process UPC 
and/or SKU information which has been manually keyed- 
in or sensed and interpreted by a device, such as a bar- 
code reader, coupled to the terminal. The computer sys- 
tem typically includes a database which stores information 
relating to the retailer's product inventory, such as 
stocked merchandise, a UPC and/or SKU number for each 
item of merchandise, and various types of merchandise 
identification information, such as price, inventory, style, 
color, size, etc., which is associated with each UPC and/or 
SKU number. When a customer purchases an item of mer- 
chandise, store personnel frequently use an automated 
terminal to read the barcode markings which are attached 
to the item. A computer interprets the UPC and/or SKU 
number comprised by the barcode, accesses the database 
to determine the price for each item, and maintains a run- 
ning total of the total transaction price. 

[0012] One problem that results from the independent identifica- 
tion schemes of the manufacturer and the retailers is that 
there is no way for the manufacturer to track the quantity 



of any particular product that each retailer sold. For ex- 
ample, even if a manufacturer obtains all of the SKU num- 
bers representing items purchased from Retailer 1 and 
Retailer 2 by consumers, the manufacturer has no means 
for determining which SKU number corresponds to the 
manufacturer's UPC, since the UPCs and SKU numbers of 
the various retailers are not tracked and matched. 
[0013] In view of the foregoing, a need exists for an incentive or 
loyalty program which overcomes the shortcomings of the 
prior art. Thus, there is a need for a system and method 
which provides a universal customer incentive program 
that networks various levels of the product distribution 
chain, such as manufacturers, wholesalers, and retailers, 
to provide incentives to consumers to purchase products 
not only from a particular merchant or group of mer- 
chants but also from particular manufacturers, who are 
not necessarily related to the specific merchant who sells 
the manufacturer's products to the consumer. Addition- 
ally, a need exists for a system and method for gathering 
data which associates particular consumer purchasing be- 
haviors and specific products or product criteria across a 

manufacturer's distribution channels. 
Summary of Invention 



[0014] jhe present invention encourages users to not only pay 
themselves first, but to pay themselves first in the largest 
amounts possible, even if they are not able to fully pay 
outstanding debts. In general, the system obtains infor- 
mation related to the user's income, income sources, 
user's debts (e.g., bills) and user's goals. The system then 
provides recommendations related to the prioritization of 
paying certain bills and the amount to pay for each bill 
based upon, for example, savings goals, minimum 
amounts due, due dates and available income. The system 
and/or the user may then determine a payment hierarchy 
which includes transferring funds to the user's savings ac- 
count prior to paying all or a portion of certain bills. 

[0015] More particularly, the invention allocates income to a user 
savings account and to user debts by receiving user finan- 
cial information, wherein the financial information in- 
cludes, for example, user income information related to 
user income, user income source information related to 
user income sources, user debt information related to 
user debts and user goal information related to user 
goals; providing at least one recommendation, wherein 
the recommendation includes, for example, suggestions 
for minimizing user debt payments and maximizing user 



savings; establishing a payment hierarchy based at least 
in part on the recommendation, wherein the payment hi- 
erarchy includes at least a portion of a payment allocated 
to the user savings account and a portion allocated to the 
user debts; acquiring user income; and, transferring user 
income, based at least in part upon the payment hierar- 
chy, to at least one of user savings account and user 
debts. The invention also monitors a consumer's purchas- 
ing activity based upon an established budget. 
Brief Description of Drawings 

[0016] The invention will hereinafter be described in conjunction 
with the appended drawing figures, wherein like numerals 
denote like elements, and: 

[0017] FIGS. 1-3 are schematic block diagrams illustrating exem- 
plary incentive systems in accordance with various aspects 
of the present invention; 

[0018] FIG. 4 is a schematic block diagram of an exemplary cen- 
tral rewards mechanism in accordance with the present 
invention; 

[0019] FIG. 5 is a schematic block diagram of an exemplary re- 
wards server in accordance with the present invention; 

[0020] FIG. 6 is a flowchart illustrating an exemplary process for 
capturing and processing POS SKU data in accordance with 



the present invention; 

[0021] FIG. 7 is a flowcliart illustrating an exemplary process for 
associating SKU data and UPC data in accordance with the 
present invention; 

[0022] FIG. 8 is a schematic block diagram illustrating an exem- 
plary virtual purchasing system in accordance with the in- 
vention; 

[0023] FIG. 9 is a schematic block diagram of an exemplary vir- 
tual purchaser in accordance with the invention; 

[0024] FIG. 10 is a flowchart illustrating an exemplary process for 
conducting a network-wide search for an item in accor- 
dance with the invention; 

[0025] FIG. 11 is a flowchart illustrating an exemplary process for 
facilitating the purchase of an item located through the 
process of FIG. 10; 

[0026] FIG. 12 is a schematic block diagram of an exemplary 

consumer purchasing analysis system in accordance with 
the invention; 

[0027] FIG. 13 is flowchart illustrating an exemplary process for 
obtaining a record of a consumer's purchasing activities; 

[0028] FIG. 14 is flowchart illustrating an exemplary process for 
analyzing a consumer's purchasing activities; 

[0029] FIG. 15 is a block diagram showing an exemplary embodi- 



ment of a system in accordance with the present inven- 
tion; and, 

[0030] FIG. 16 is a flow chart showing an exemplary embodiment 

of a method for implementing the present invention. 
Detailed Description 

[0031] The detailed description of exemplary embodiments of 

the invention herein makes reference to the accompanying 
drawings, which show the exemplary embodiment by way 
of illustration and its best mode. While these exemplary 
embodiments are described in sufficient detail to enable 
those skilled in the art to practice the invention, it should 
be understood that other embodiments may be realized 
and that logical and mechanical changes may be made 
without departing from the spirit and scope of the inven- 
tion. Thus, the detailed description herein is presented for 
purposes of illustration only and not of limitation. For ex- 
ample, the steps recited in any of the method or process 
descriptions may be executed in any order and are not 
limited to the order presented. 

[0032] As used herein, the terms "user" and "participant" shall in- 
terchangeably refer to any person, entity, charitable orga- 
nization, machine, hardware, software, or business who 
accesses and uses the system of the invention, including 



consumers, retailers, manufacturers, and third-party 
providers. Participants in tlie system may interact with one 
another either online or off-line. 

[0033] As used herein, the term "online" refers to interactive 

communications that take place between participants who 
are remotely located from one another, including commu- 
nication through any of the networks or communications 
means described above or the like. 

[0034] The term "manufacturer" shall include any person, entity, 
charitable organization, machine, software, hardware, 
and/or the like that manufactures, distributes, or origi- 
nates a product or service which may ultimately be offered 
to a consumer directly or indirectly through a retailer. The 
term "manufacturer" may also include any party that gen- 
erates and/or provides manufacturer item identifiers. 

[0035] The term "retailer" shall include any person, entity, chari- 
table organization, machine, software, hardware, and/or 
the like that that offers a product or service to a con- 
sumer. As used herein, the term "retailer" is used inter- 
changeably with the term "merchant". Moreover, in this 
context, a retailer or merchant may offer or sell, either 
online or off-line, products and/or services made or sup- 
plied by at least one manufacturer. 



[0036] As used herein, the phrases "network level" and "network- 
wide level" shall refer to a system that includes more than 
one retailer and at least one manufacturer. 

[0037] As used herein, the terms "purchaser", "customer", "con- 
sumer", and "end-user" may be used interchangeably with 
each other, and each shall mean any person, entity, chari- 
table organization, or business which uses a consumer ID 
to participate in the present system. 

[0038] A "consumer ID", as used herein, includes any device, 
code, or other identifier suitably configured to allow the 
consumer to interact or communicate with the system, 
such as, for example, a rewards card, charge card, credit 
card, debit card, prepaid card, telephone card, smart card, 
magnetic stripe card, bar code card, transponder, autho- 
rization/access code, personal identification number (PIN), 
Internet code, other identification code, and/or the like. 
Additionally, a "consumer ID" may comprise any form of 
radio wave, electronic, magnetic, and/or optical device 
capable of receiving (uploading) and/or transmitting 
(downloading) data to and/or from itself to a second de- 
vice which is capable of interacting and communicating 
with such forms of consumer ID. 

[0039] "Consumer enrollment data" may comprise any of the fol- 



lowing: name; address; date of birth; social security num- 
ber; email address; gender; the names of any household 
members; survey data; interests; educational level; and/or 
any preferred brand names. A consumer may register to 
participate in the present system by any methods known 
and practiced in the art. For example, a consumer may be 
enrolled automatically (e.g., if the consumer holds an ex- 
isting consumer account with the system administrator), 
over the phone, at the point of sale (e.g., through a paper 
application or a verbal interview), through the mail, or 
through instant enrollment online. Upon enrollment, the 
consumer receives a consumer ID that is associated with a 
consumer account. 
[0040] In an exemplary aspect, "consumer enrollment data" may 
also comprise a transaction card number for charging any 
fees that may be associated with participation in the sys- 
tem and/or for facilitating the purchase of goods and ser- 
vices through the virtual purchasing system described be- 
low. In this context, a "transaction card number" may in- 
clude any device, code, or suitable financial instrument 
representing an account with a financial institution, such 
as a bank, a card issuer, and/or the like, wherein the de- 
vice, code, or other suitable financial instrument has a 



credit line or balance associated with it, and wherein the 
credit line or balance is in a form of financial tender hav- 
ing discrete units, such as currency. Moreover, a "transac- 
tion card number", a "transaction card", or a "card", as 
used herein, includes any device, code, or financial instru- 
ment suitably configured to allow the cardholder to inter- 
act or communicate with the system, such as, for exam- 
ple, a charge card, credit card, debit card, prepaid card, 
telephone card, smart card, magnetic stripe card, bar code 
card, authorization/access code, personal identification 
number (PIN), Internet code, other identification code, 
and/or the like. 

[0041] A "consumer profile", as used herein, shall refer to any 

data used to characterize a consumer and/or the behavior 
of a consumer. In the context of a commercial transaction, 
"a consumer profile" shall be understood to include, for 
example, the time and date of a particular purchase, the 
frequency of purchases, the volume/quantity of pur- 
chases, the transaction size (price), and/or the like. Addi- 
tionally, in other transactional contexts, the term "con- 
sumer profile" shall also be understood to include non- 
purchase behaviors of a consumer, such as consumer en- 
rollment data, visiting a Web site, referrals of prospective 



participants in tlie system, completion of a survey or other 
information gathering instrument, and/or the lil<e. For in- 
stance, a participating online consumer may earn rewards 
points automatically through a triggering event, such as 
visiting a Web site, completing an online survey, or click- 
ing on a banner advertisement for example. Off-line, a 
participating consumer may earn rewards points by com- 
pleting a task or showing their consumer ID to the cashier 
and triggering the cashier to provide a "behavior" ID which 
may be input (e.g., by scanning a bar code on a paper 
survey for example) into the POS terminal. Further, any 
aspects of the consumer profile may be used in the con- 
text of data analysis. 
[0042] A "third-party provider" may comprise any additional 

provider of goods and/or services to a consumer. Specifi- 
cally, a "third-party provider" includes any party other 
than the particular manufacturer and retailer who is in- 
volved in a transaction with a consumer. A third-party 
provider may include, for example, a financial institution, 
such as a bank or an issuer of a financial instrument (such 
as a credit card or a debit card). A third-party provider 
may also include a provider of goods and services which 
are offered as awards to consumers in exchange for a 



requisite number of reward points. 
[0043] Tliough the invention may generically be described witli 
reference to a series of transactions which transfer a good 
or service from an originating party to an intermediary 
party and a subsequent transaction which transfers the 
good or service from the intermediary party to an end- 
user of that good or service, for convenience and pur- 
poses of brevity and consistency, the present disclosure 
generally refers to the originating party as a "manufac- 
turer", the intermediary party as a "retailer", the end-user 
as a "consumer", and a good or service as a "product" or 
"item". However, it will be recognized by those of ordinary 
skill in the art that the retailer need not provide a product 
or item to a consumer in exchange for monetary currency. 
While this often may be the case, the present disclosure is 
not so limited and includes transactions which may be 
gratuitous in nature, whereby the retailer transfers a 
product or item to a consumer without the consumer pro- 
viding any currency or other value in exchange. It is fur- 
ther noted that additional participants, referred to as 
third-party providers, may be involved in some phases of 
the transaction, though these participants are not shown. 
Exemplary third-party providers may include financial in- 



stitutions, such as banks, credit card companies, card 
sponsoring companies, or issuers of credit wlio may be 
under contract witli financial institutions. It will be appre- 
ciated that any number of consumers, retailers, manufac- 
turers, third-party providers, and the like may participate 
in the system of the present invention. 

[0044] As used herein, the term "UPC" and the phrase "manufac- 
turer item identifier" shall refer to any symbol or indicia 
which provides information and, in an exemplary embodi- 
ment, shall refer to any number, code, or identifier as- 
signed by a manufacturer and associated with an item, in- 
cluding any type of goods and/or services, ultimately of- 
fered to a consumer or other end-user. Colloquially, a 
UPC is sometimes referred to as a SKU number. However, 
as used herein, the term "SKU" and the phrase "retailer 
item identifier" shall refer to any symbol or indicia which 
provides additional information and, in an exemplary em- 
bodiment, shall refer to any number, code, or identifier 
assigned by a retailer and associated with an item, includ- 
ing any type of goods and/or services, offered to a con- 
sumer or other end-user. 

[0045] "Purchase data", as used herein, comprises data relating 
to the offer of any item to a consumer or other end-user. 



Purchase data may include any of the following: an item 
purchased, an item price, a number of items purchased, a 
total transaction price, a payment vehicle, a date, a re- 
tailer ID, a store ID, an employee identifier, a retailer item 
identifier, a manufacturer ID, a manufacturer item identi- 
fier, a loyalty identifier, and/or the like. 
[0046] "Retailer ID" or "retailer identifier", as used herein, com- 
prises any symbol, indicia, code, number, or other identi- 
fier that may be associated with a retailer of any type of 
goods and/or services offered to a consumer or other 
end-user. A retailer ID may also include or be associated 
with a "store ID", which designates the location of a par- 
ticular store. 

[0047] A "manufacturer ID" or "manufacturer identifier" com- 
prises any symbol, indicia, code, number, or other identi- 
fier that may be associated with a manufacturer of any 
type of goods and/or services ultimately offered to a con- 
sumer or other end-user. 

[0048] An "award" or "reward" may comprise any quantity of 

products, services, coupons, gift certificates, rebates, re- 
ward points, bonus points, credits or debits to a financial 
instrument, any combination of these, and/or the like. 

[0049] "Data analysis", as used herein, shall be understood to 



comprise quantitative and qualitative research, statistical 
modeling, regression analyses, market segmentation 
analyses, econometrics, financial analyses, budgeting 
analyses, and/or the like. Such analyses may be used to 
predict consumer behaviors and/or correlate consumer 
profiles, retailer data, manufacturer data, and/or product 
or service data. Such analyses may also be used to moni- 
tor a consumer's personal finances by enabling a con- 
sumer to track their spending behaviors and patterns, as 
an individual or as part of a family, organization or other 
group. 

[0050] The system of the present invention associates or maps 

manufacturer UPC data and retailer SKU data on a network 
level to reward consumers and/or to analyze the data for 
a variety of business purposes, such as market segmenta- 
tion analyses and/or analyses relating to consumer 
spending behaviors or patterns for example. Rather than 
simply capturing transactions at a Record of Charge (ROC) 
level, that is, recording consumer purchases in a general 
fashion by designating purchase categories (such as 
"clothing", "electronics", or "hardware" for example), the 
system identifies the particular item purchased (such as 
"jeans", "stereo", or "hammer" for example) as well as its 



corresponding manufacturer. By matching or associating 
the retailer SKU and the manufacturer's UPC, the system 
permits the standardization of goods and/or services 
codes at the networl< level. This standardization not only 
permits a record of both the specific item purchased and 
its manufacturer, regardless of the particular retailer in- 
volved in the transaction, but it permits the mapping of 
multiple consumers, multiple goods and/or services, mul- 
tiple retailers, and/or multiple manufacturers to advanta- 
geously cross-market goods and services to consumers. 
[0051] In accordance with one aspect of the invention, the asso- 
ciation of UPC and SKU data by the system facilitates im- 
plementation of an incentive or loyalty program by pro- 
viding a universal rewards currency which may be "spent" 
by participants who have earned rewards and accepted by 
the other participants in the multi-tiered network created 
by the system. The network may comprise any number of 
participants, including consumers, retailers (and any of 
their employees), manufacturers, third-party providers, 
and the like. Each of these categories of participants may 
be considered a tier in the network, and each participant 
within the various tiers may design and implement an in- 
dependent rewards scheme within the context of the uni- 



versal environment provided by tlie system. For example, 
l\/lanufacturer 1 may produce and assign a UPC to Item X. 
Item X may subsequently be offered for sale by both Re- 
tailer 1 and Retailer 2. Retailer 1 and Retailer 2 may then 
each assign an independent SKU number to Item X to fa- 
cilitate their own tracking, inventory, and pricing schemes. 
A consumer may then purchase Item X from both Retailer 
1 and Retailer 2. 
[0052] Since the system is capable of processing, associating, 
and quantifying a variety of data, including consumer 
data, employee data, retailer data, manufacturer data, SKU 
number data corresponding to Item X, and UPC data as- 
signed by Manufacturer 1, for example, this data can then 
be used by the manufacturer, the retailer, the system ad- 
ministrator, and/or a third-party provider to provide re- 
wards to consumers, employees, retailers, etc. For exam- 
ple, a manufacturer may provide frequency-based incen- 
tives, such as every 10th purchase of a particular item will 
be discounted by 50% for example, independent of and/or 
in addition to any incentives offered by the specific re- 
tailer involved in the transaction. Additionally, the manu- 
facturer may provide sales incentives to the employees of 
retailers independent of and/or in addition to any em- 



ployee incentive programs tliat tlie retailers may clioose 
to implement. 

[0053] Since rewards, which may be in the form of rewards 

points, may be earned across the various tiers in the net- 
work, rewards may also be used or spent across the vari- 
ous tiers in the network. Thus, any rewards points that an 
employee, for example, may earn by promoting a particu- 
lar manufacturer's line of products, may be "spent" by that 
employee on goods or services provided by any partici- 
pant in the network, not merely at the retailer who em- 
ploys that employee. Likewise, any rewards points earned 
by a consumer may be spent on goods or services offered 
by any participant in the network. 

[0054] In accordance with another aspect of the invention, the 
association of UPC and SKU data by the system facilitates 
data analysis on a network level based upon several fac- 
tors, including any of the following: consumer ID, con- 
sumer profile, retailer ID, SKU number, UPC, manufacturer 
ID, and/or the like. The system may compile any of the 
above data across multiple participants for the purpose of 
data analysis, such as analyses which may be employed in 
strategic planning and marketing for example. The system 
of the invention may be used to compile, analyze, and re- 



port data in a manner which would inform any or all net- 
work participants that, for example, a specific consumer 
(1) has made multiple purchases of particular manufactur- 
ers" products; (2) has spent Q dollars over a certain time 
period; (3) at specific multiple retailers; and (4) of the 
purchases made, R dollars went towards the purchase of 
Product 1, S dollars went towards the purchase of Product 
2, and T dollars went towards the purchase of Service 1. 
Moreover, the system may be used to compile, analyze, 
and report data that enable a retailer, a manufacturer, 
and/or a third-party provider to create a variety of tar- 
geted marketing promotions, such as, for example, (1) 
marketing Product 1 offered by Manufacturer 1 to con- 
sumers who purchase Product 2 offered by Manufacturer 
2; (2) marketing Product 1 offered by Manufacturer 1 and 
sold by Retailer X to consumers who purchase Product 2 
offered by Manufacturer 2 at Retailer Y; and/or (3) mar- 
keting Product 1 offered by Manufacturer 1 and sold by 
Retailer X to consumers who purchase Product 2 offered 
by Manufacturer 2 at Retailer Y five times a year. It will be 
appreciated that these are but a few of the many possible 
applications for data gathered and generated by the sys- 
tem of the present invention. 



[0055] In accordance with a further aspect of the invention, the 
system administrator may allocate rewards points to par- 
ticipants in the system. In one embodiment, participating 
retailers and/or manufacturers may purchase points from 
the system administrator and the points are then allocated 
to an account associated with the retailer and/or manu- 
facturer. In an alternate embodiment, the system adminis- 
trator may give or donate points to participating retailers 
and/or manufacturers. The system administrator main- 
tains an account with each of the participating retailers 
and manufacturers and tracks available points balances 
and/or balances owing on a rolling basis. The points pur- 
chased by the retailers and/or manufacturers may then be 
earned by and issued to consumers in a manner that is 
predetermined by the retailer and/or manufacturer in- 
volved in the transaction with the consumer. For example. 
Retailer 1 may purchase 10,000 points from the system 
administrator and then offer consumers 1 point for every 
$10 dollars spent in Retailer I's store or, perhaps, some 
number of points for every fifth transaction in the store. 
Moreover, Manufacturer 1, who produces the product of- 
fered by Retailer 1, may also purchase points from the 
system administrator. Thus, when a consumer purchases 



Manufacturer l"s product at Retailer 1, Manufacturer 1 
may issue some number of points to tlie consumer. Tlie 
issuance of points, eitlier by retailers or manufacturers, 
may be based upon any selected criteria, including a 
points-for-dollars ratio, a defined quantity of points per 
item or per transaction, some combination of these, and/ 
or the like. 

[0056] The system administrator maintains an account for each 
participating consumer and apprises the consumer of the 
points totals and account activity. The consumer may re- 
view the total number of points in the account either on- 
line or off-line, such as through a periodic statement sent 
by the system administrator or through the use of a com- 
munications network, such as the Internet, for example. 
Points in the consumer's account are accumulated across 
the multiple retailers and/or manufacturers participating 
in the system. Thus, points earned by a consumer based 
upon transactions with different retailers and/or manu- 
facturers are combined, resulting in a rapid accrual of 
points. The system administrator offers a catalog of prod- 
ucts and services, which may be either online or off-line, 
from which consumers may select rewards in exchange 
for accrued points. In this manner, consumers advanta- 



geously earn points based upon their everyday purchases 
of products and services, these points are accrued across 
retailers and/or manufacturers, and points redemption 
tal<es place through a single, universal catalog of rewards. 

[0057] In accordance with the present invention, FIG. 1 is a dia- 
gram illustrating an exemplary embodiment of an incen- 
tive or loyalty system 100. System 100 comprises a cen- 
tral rewards mechanism 102; a plurality of retailer/mer- 
chant systems 104; and at least one manufacturer 106. 
One skilled in the art will appreciate that system 100 may 
comprise any number of retailer systems 104 and any 
number of manufacturers 106. 

[0058] The central rewards mechanism 102 manages the incen- 
tive or loyalty program of the system 100. In an exem- 
plary embodiment, central rewards mechanism 102 re- 
ceives, processes, and stores manufacturer data, such as 
information regarding products and/or services and UPC 
data, transmitted by manufacturers 106 who have en- 
rolled in the system 100. Manufacturers 106 may transmit 
data to central rewards mechanism 102 in any form and 
by any means known in the art, including any of the com- 
munications means described above. The manufacturer 
data is stored by the central rewards mechanism 102 in 



database 103. Database 103 may be any type of database, 
such as relational, hierarchical, object-oriented, and/or 
the like. Common database products that may be used to 
implement database 103 include DB2 by IBM (White Plains, 
NY), any of the database products available from Oracle 
Corporation (Redwood Shores, CA), Microsoft Access by 
Microsoft Corporation (Redmond, Washington), or any 
other database product. Database 103 may be organized 
in any suitable manner, including as data tables or lookup 
tables. 

[0059] The central rewards mechanism 102 may receive and pro- 
cess consumer ID information and purchase data from any 
of the retailer systems 104. The central rewards mecha- 
nism 102 may also associate a particular consumer ID 
with the purchase data and a corresponding manufacturer 
item identifier. In one embodiment, the central rewards 
mechanism 102 performs an analysis involving any of the 
following: a consumer ID, purchase data, a points ratio, a 
consumer profile, a retailer ID, and a manufacturer ID. The 
analysis may be dependent upon an the association of the 
consumer IDs, the purchase data, and the manufacturer 
item identifier. The analysis may further comprise, for ex- 
ample, a calculation of rewards points and/or other analy- 



ses for purposes of market segmentation, determining 
consumer spending beliavior, correlating spending behav- 
ior and consumer demographics, and/or the like, as de- 
scribed in greater detail above. 
[0060] In one exemplary embodiment, the central rewards mech- 
anism 102 stores and informs a consumer of the rewards 
points that have been earned by a particular transaction 
as well as accumulated over time. The number of rewards 
points calculated and awarded by the central rewards 
mechanism 102 for a particular purchase may depend 
upon a predetermined rewards ratio. The rewards ratio 
may be determined by the retailer, the system administra- 
tor, the manufacturer of the purchased item, and/or any 
other suitable third-party. For example, if a participating 
consumer buys a product from a retailer for $100 and if 
the retailer rewards ratio is one reward point for each dol- 
lar of the purchase price (i.e., one-for-one), once the con- 
sumer's consumer ID is identified by the system, the con- 
sumer is credited with a suitable number of rewards 
points from the retailer, which, in this case, would be 100 
points. However, if the manufacturer also chooses to issue 
rewards points for the item purchased, the manufacturer 
may select a points ratio that is different from the re- 



tailer's selected ratio. In the illustrated example, if the 
manufacturer's selected points ratio is two-for-one, then 
the consumer will be awarded an additional 200 points 
from the manufacturer for this single $100 purchase. In 
this manner, the system of the invention may provide 
"earn accelerators" through which consumers may accu- 
mulate rewards points at a comparatively rapid rate. In 
other words, a single purchase may generate rewards 
points for a consumer from any or all of a retailer, a man- 
ufacturer, and/or a third-party provider, and those re- 
wards points may be used as rewards currency by the 
consumer throughout the network established by the sys- 
tem of the invention. 
[0061] In an exemplary embodiment, retailer system 104 com- 
prises a retailer terminal 108 and a retailer processor 110 
in communication with database 111. Retailer terminal 
108 comprises any device capable of identifying a con- 
sumer ID. Exemplary devices for identifying a consumer ID 
may include: a conventional card reader which recognizes 
a magnetic stripe or bar code associated with a consumer 
ID; a biometric device; a smart card reader which recog- 
nizes information stored on a microchip integrated with a 
consumer ID; and any device capable of receiving or up- 



loading consumer ID data transmitted electronically, mag- 
netically, or optically; and/or the like. In one embodiment, 
retailer terminal 108 and retailer processor 110 are co- 
located at a retail store. In another embodiment, retail 
terminal 108 and retailer processor 110 are remote from 
each other. 

[0062] In an exemplary embodiment, as illustrated in FIG. 2, re- 
tailer terminal 108 comprises a retailer POS terminal 112, 
such as a cash register or an online retailer Web site, for 
example. When a consumer ID is used at the time an item 
is purchased, purchase data, including a SKU number, is 
input, sensed, or otherwise recognized by terminal 108, 
and then the purchase data is processed and stored by re- 
tailer processor 110. Retailer processor 110 comprises or 
is in communication with a suitable database 111 or other 
storage device for maintaining and storing purchase data 
and any other suitable retailer information. Database 111 
may be any type of database, such as any of the database 
products described above for example. Database 111 may 
be organized in any suitable manner, including as data ta- 
bles or lookup tables. Purchase data that is stored in 
database 111 is available to the retailer's local back office 
system (not shown) for inventory, accounting, tax, data 



analysis, and other purposes. The captured purchase data 
may include the item purchased, the item's unit price, the 
number of items purchased, the date, the store location, 
an employee ID, and any other information related to the 
purchase. In an exemplary embodiment, retailer processor 
110 may also receive, process, and store manufacturer 
data, such as information regarding products and/or ser- 
vices and UPC data, from manufacturers 106 who have 
enrolled in the system 100. The manufacturer data may be 
stored in any suitable form, including data tables or 
lookup tables. 

[0063] In accordance with the exemplary embodiments illustrated 
in FIG. 3, purchase data may also be transmitted to, and 
then processed and stored by, a retailer regional proces- 
sor 114 (or, alternatively, a retailer national processor (not 
shown)) in communication with database 115 for the pur- 
pose of further back office and cumulative data analysis. 
Database 115 may be any type of database, such as any of 
the database products described in greater detail above 
for example. Database 115 may be organized in any suit- 
able manner, including as data tables or lookup tables. In 
an exemplary embodiment, retailer processor 110 option- 
ally may be integrated with retailer regional processor 114 



(illustrated by the phantom lines encompassing Retailer 
Processor 1 and retailer regional processor 114 within the 
system of Retailer/Merchant #2), thereby forming a single 
device. In another embodiment, retailer processor 110 
and retailer regional processor 114 are separate devices 
which may be either co-located with each other or re- 
motely located from one another. For example, in one 
embodiment, retailer processor 110 and regional proces- 
sor 114 are co-located at a particular retail store. In an- 
other embodiment, retailer processor 110 is located at a 
particular retail store and retailer regional processor 114 
is remotely located at a regional office. 
[0064] Regardless of the location of retailer regional processor 
114, retailer regional processor 114 receives and pro- 
cesses similar information from each of the retailer pro- 
cessors 110 associated with each of the retail stores 
owned by the same retailer. Whether the system 100 com- 
prises a retailer regional processor 114 or a retailer na- 
tional processor may be a function of the number of 
stores maintained by a particular retailer. That is, a larger 
retailer who has numerous stores throughout the country, 
for example, may choose to have a plurality of regional 
processors, while a smaller retailer with a few stores scat- 



tered across the country may be better served by a single, 
national processor. In exemplary embodiments, the re- 
tailer regional processors 114 and/or national processors 
communicate with a suitable database 115 or other stor- 
age device which is configured to store and maintain pur- 
chase data and any other suitable retailer information. In 
another exemplary embodiment, retailer regional proces- 
sor 114 may receive, process, and store manufacturer 
data, such as information regarding products and/or ser- 
vices and UPC data, from manufacturers 106 who have 
enrolled in the system 100. The manufacturer data may be 
stored in any suitable form, including data tables or 
lookup tables. 

[0065] vVith momentary reference to FIG. 2, retailer terminal 108 
may comprise a rewards terminal 116 through which a 
consumer may be updated with regard to various aspects 
of the system. For example, rewards terminal 116 may in- 
form a consumer of the number of reward points that they 
have accumulated from all system participants and the 
types of awards that may be obtained using those reward 
points. Moreover, rewards terminal 116 may suggest to 
the consumer various awards for which the consumer is 
eligible based upon the rewards points generated by the 



consumer's network-wide purchases. In this context, net- 
worl<-wide purchases include any purchases of items cor- 
responding to retailers and/or manufacturers participat- 
ing in the system 100. 
[0066] In an exemplary embodiment, rewards terminal 116 oper- 
ates in real-time. In this context, "real-time" means that 
reward points are immediately, or nearly immediately, up- 
dated at the time purchases are made and are therefore 
immediately redeemable by the consumer at the a point of 
sale. Thus, for example, a consumer may be informed by 
rewards terminal 116 at the point of sale that the item be- 
ing purchased by the consumer may be purchased using 
the consumer's accumulated reward points, including 
points accumulated on a network level. Points accumu- 
lated on a network level enable consumers to accumulate 
points more rapidly than would be possible if only a single 
retailer or group of retailers were issuing the points. In 
one embodiment, rewards terminal 116 may update a 
consumer's rewards points in real-time and, in response 
to the consumer's particular points total, issue a coupon, 
a gift certificate, and/or additional bonus points to the 
consumer. 

[0067] In another exemplary embodiment, the system may oper- 



ate in batch mode, wherein points totals are calculated, 
stored, and periodically updated for access by the retailer 
terminal 108, including POS terminal 112 and/or rewards 
terminal 116. Thus, in this embodiment, the consumer 
may be notified of available points sometime after a pur- 
chase, or a suggestive sale may take place after a pur- 
chase. The total point count or suggestive sale may take 
into account points generated and accumulated as the re- 
sult of network-wide purchases. 
[0068] In various alternate embodiments of the invention, retailer 
terminal 108 may include a rewards terminal 116 but not 
a POS terminal 112; a POS terminal 112 but not a rewards 
terminal 116; or a POS terminal 112 in communication 
with a rewards terminal 116. In alternate embodiments, 
where terminal 108 includes a POS terminal 112 and a re- 
wards terminal 116, the two terminals 112 and 116 may 
be variously implemented as separate terminals, inte- 
grated terminals, or software within a device. In another 
embodiment, where terminal 108 comprises a rewards 
terminal 116 but not a POS terminal 112, terminal 108 
may be a kiosk terminal located within a retail store or 
some other remote terminal which is capable of recogniz- 
ing a consumer ID and communicating with the system 



100. A consumer may use independent rewards terminal 
116 to do, for example, any of the following: view accu- 
mulated reward points totals; view potential awards which 
the consumer may obtain in exchange for various num- 
bers of points; select an award; redeem rewards points for 
a selected award; request and/or receive a reward points 
advisory statement; and/or view a directory of participat- 
ing retailers, manufacturers, and third-party providers. 
[0069] In another exemplary embodiment, system 100 further 
comprises a consumer terminal 118. Consumer terminal 
118 is any remote terminal through which a consumer 
may access other aspects of the system 100. Consumer 
terminal 118 may comprise any of the input devices, com- 
puting units, or computing systems described above. Fur- 
ther, consumer terminal 118 communicates with the sys- 
tem 100 through any of the communications networks 
described above. In one embodiment, consumer terminal 
118 permits a consumer to engage multiple facets of the 
system 100 in an interactive online communications envi- 
ronment. The interactive online environment made avail- 
able through consumer terminal 118 is an extension of 
the network-level incentive award program and is imple- 
mented in conjunction with other aspects of the system 



100. In this context, a consumer may use consumer ter- 
minal 118 for a variety of purposes. In one embodiment, 
consumer terminal 118 may be used to communicate with 
and receive information from the central rewards mecha- 
nism 102. For example, a consumer may use consumer 
terminal 118 to do any of the following: enroll in the sys- 
tem; receive statements or reports regarding accumulated 
reward points totals; receive bonus details; view potential 
awards which the consumer may obtain in exchange for 
various numbers of points; select an award; receive re- 
demption information; view points adjustments; redeem 
rewards points for a selected award; request and/or re- 
ceive a reward points advisory statement; receive infor- 
mation regarding where and how points were earned and/ 
or how points were redeemed; receive information re- 
garding expiration dates for points earned; receive infor- 
mation relating to any applicable fees; receive information 
regarding marketing promotions; and/or view a directory 
of participating retailers, manufacturers, and/or third- 
party providers. 

[0070] In another embodiment, consumer terminal 118 may be 

used to interact with and/or make purchases and generate 
rewards points from participating online retailers, as illus- 



trated by the various phantom lines in FIG. 1. The online 
retailer may then communicate with the central rewards 
mechanism 102 to transmit and process a consumer ID, 
purchase data, etc., as described above with reference to 
retailer 104 of FIG. 1. Information communicated between 
the online consumer, the online retailer, and the online 
central rewards mechanism may include, for example, 
product or service information, prices, availability of the 
product or service, shipping information, rewards points 
information, available awards, information regarding 
points ratios and points redemption, and/or the like. In 
one embodiment, consumer terminal 118 operates in 
real-time, as described above with respect to rewards ter- 
minal 116. In another embodiment, the consumer termi- 
nal 118 may operate in batch mode, as described above. 
In still a further embodiment, consumer terminal 118 op- 
erates in a manner which includes aspects of both real- 
time functionality and batch mode functionality. 
[0071] In accordance with a further aspect of the invention, the 
system 100 may comprise a rewards server 120 in com- 
munication with a database 121, as illustrated in FIG. 2. 
Database 121 may be any type of database, such as any of 
the database products described above for example. 



Database 121 may be organized in any suitable manner, 
including as data tables or lookup tables. In an exemplary 
embodiment, rewards server 120 may be any hardware 
and/or software that is configured to communicate with 
the central rewards mechanism 102 and either the retailer 
processor 110 or the retailer regional processor 114. In 
alternate exemplary embodiments, rewards server 120 
may be integrated with retailer system 104; rewards 
server 120 may be integrated with central rewards mecha- 
nism 102; or rewards server 120 may be separate from 
both retailer system 104 and central rewards mechanism 
102. In a further embodiment, the rewards server 120 
may communicate with both a retailer national processor 
(not shown) and the central rewards mechanism 102. 
[0072] In an exemplary embodiment, rewards server 120 re- 
ceives, processes, and stores both manufacturer data and 
retailer data. Manufacturer data may include descriptions 
of products and/or services and UPC data transmitted 
from manufacturers 106 who have enrolled in the system 
100. The manufacturer data may be stored in any suitable 
form, including data tables or lookup tables. Retailer data 
may include descriptions of products and/or services and 
SKU data transmitted from retailers 104 who have enrolled 



in the system 100. The retailer data may be stored in any 
suitable form, including data tables or lookup tables. 
[0073] In an exemplary embodiment, the rewards server 120 

performs a plurality of functions that might otherwise be 
performed by the central rewards mechanism 102. For 
example, since rewards calculations require significant 
processing and memory resources, performance of calcu- 
lations processing by the rewards server 120 at the re- 
gional level lessens the processing load on the central re- 
wards mechanism 102, thereby increasing the efficiency 
of the central rewards mechanism 102. In an exemplary 
embodiment, each retailer's region, which comprises a 
plurality of that retailer's stores or outlets, accesses a re- 
wards server 120 which acts as an intermediary between 
the retailer regional processor 114 and the central re- 
wards mechanism 102. This configuration relieves the 
processing, power, memory, and other requirements of 
the central rewards mechanism 102. Moreover, each re- 
tailer is but one of many retailers that may participate in 
the network level rewards structure. Accordingly, a plural- 
ity of rewards servers 120 may be in communication with 
the central rewards mechanism 102 as well as each of the 
participating retailer regional processors 114, further al- 



leviating the processing burden and freeing up the re- 
sources of the central rewards mechanism 102. 
[0074] Implementations which include at least one independent 
rewards server 120 are also advantageous because cost- 
effective communications links may be used to facilitate 
communications with the central rewards mechanism 102. 
Performance by the rewards server 120 of many of the "in- 
telligence functions" of the system 100, permits transmis- 
sion of only particular forms of purchaser information to 
the central rewards mechanism 102. In an exemplary em- 
bodiment, data sent from the rewards server 120 to the 
central rewards mechanism 102 may include the con- 
sumer ID and the total number of rewards points earned 
by a consumer in a particular transaction. In another ex- 
emplary embodiment, data transmitted by the rewards 
server 120 to the central rewards mechanism 102 may 
also include any pre-selected aspect of the consumer 
profile, any pre-selected aspect of the purchase data, 
and/or any other pre-selected data associated with a con- 
sumer, a retailer, a manufacturer, and/or a third-party 
provider. Pre-selection of the types of data transmitted by 
the rewards server 120 to the central rewards mechanism 
102 may be conducted by the system administrator, a re- 



tailer, a manufacturer, and/or a third-party provider. 
Tlius, data which may be useful for purposes of data anal- 
ysis but unrelated to the rewards feature, such as the 
characteristics of the particular item purchased for exam- 
ple, may not need to be transmitted to the central rewards 
mechanism 102. 

[0075] Exemplary functions performed by the rewards server 120 
may include the association of UPC and SKU data; manip- 
ulation of the rewards criteria applicable in particular 
cases, which may further depend upon the retailer, manu- 
facturer, and/or third-party provider involved in a specific 
transaction with a consumer; calculation of rewards bene- 
fits earned by the consumer; filtration functions for deter- 
mining which data is transmitted from the rewards server 
120 to the central rewards mechanism 102; and/or vari- 
ous types of data analyses, as described above. In an ex- 
emplary embodiment, the retailer system 104 houses, 
maintains, and updates the hardware and/or software of 
the rewards server 120. In another embodiment, rewards 
server 120 may be housed, maintained, and updated by 
the system administrator. 

[0076] In accordance with another embodiment of the present in- 
vention, the system 100 permits an open payment system. 



Since the invention generally provides that consumer par- 
ticipation in the system is based upon a consumer ID, a 
purchaser may use any of multiple payment vehicles (such 
as cash, check, charge card, credit card, debit card, Mas- 
terCard®, Visa®, and/or the American Express® Card for 
example) to make purchases at the various retailers and 
still participate in the system. Thus, in one embodiment, 
the consumer ID is independent of any particular payment 
vehicle, such as a credit card for example. 
[0077] However, alternate embodiments of the invention may be 
implemented which associate a consumer ID with a partic- 
ular payment vehicle, such as a consumer's credit card ac- 
count, charge card account, debit card account, and/or 
bank account for example. In this embodiment, the re- 
tailer conducting the transaction need only participate in 
the system to the extent that the retailer provides its SKU 
data to the system 100, such as to the rewards server 
120. In other words, when a consumer ID is associated 
with an instrument (e.g., a credit card) from a third-party 
provider, the retailer need not provide a rewards terminal 
or other terminal capable of processing the consumer ID, 
since the third-party provider may process the consumer 
ID as part of the payment transaction. Thus, in this em- 



bodiment, rewards benefits may be earned by the con- 
sumer on a network-wide level without the retailer's direct 
participation in the rewards feature (notwithstanding the 
retailer's participation in transmitting SKU data to the sys- 
tem). Moreover, it will be appreciated that a single con- 
sumer ID may be associated with multiple third-party 
payment vehicles, thereby allowing a consumer to gener- 
ate rewards points regardless of the particular payment 
vehicle selected for a particular purchase. 
[0078] vvith reference to FIG. 4, an exemplary central rewards 

mechanism 402 includes a central processor 404 in com- 
munication with other elements of the rewards mecha- 
nism 402 through a system interface or bus 406. A suit- 
able display device / input device 408, such as a keyboard 
or pointing device in combination with a monitor, may be 
provided for receiving data from and outputting data to a 
user of the system. A memory 410, which is associated 
with the rewards mechanism 402, includes various soft- 
ware modules, such as an enrollment module 412 and an 
authentication module 414 for example. The memory 410 
preferably further includes an operating system 416 which 
enables execution by central processor 404 of the various 
software applications residing at enrollment module 412 



and authentication module 414. Operating system 416 
may be any suitable operating system, as described 
above. Preferably, a network interface 418 is provided for 
suitably interfacing with other elements of the incentive 
awards system, such as the elements described above 
with reference to FIGS. 1-3. 
[0079] Lastly, a storage device 420, such as a hard disk drive for 
example, preferably contains files or records which are 
accessed by the various software modules, such as enroll- 
ment module 412 and authentication module 414. In par- 
ticular, consumer data 422 comprises information re- 
ceived from a consumer upon registration with the re- 
wards mechanism 402. Consumer rewards 424 comprises 
data corresponding to each consumer's rewards account. 
Consumer rewards 424 may include cumulative rewards 
points totals as well as historical totals and rewards ac- 
count activity over time. Retailer records 426 comprises 
information received from the various participating retail- 
ers. Manufacturer records 428 comprises information re- 
ceived from the various participating manufacturers. One 
skilled in the art will appreciate that the storage device 
420 and, therefore, consumer data 422, consumer re- 
wards 424, retailer records 426, and manufacturer 



records 428 may be co-located with the rewards mecha- 
nism 402 or may be remotely located with respect to the 
rewards mechanism 402. If the storage device 420 is re- 
motely located with respect to the rewards mechanism 
402, communication between storage device 420 and re- 
wards mechanism 402 may be accomplished by any suit- 
able communication link but is preferably accomplished 
through a private intranet or extranet. 

[0080] Enrollment module 412 receives information from con- 
sumers, retailers, and/or manufacturers who wish to par- 
ticipate in the system. Enrollment module 412 accesses 
and stores information in storage device 420. Authentica- 
tion and/or validation of the identity and status of partici- 
pants, including any of the other system components, 
may be performed by the authentication module 414, 
which preferably has access to the records residing in 
storage device 420. 

[0081] vvith reference to FIG. 5, an exemplary rewards server 502 
includes a central processor 504 in communication with 
other elements of the rewards server 502 through a sys- 
tem interface or bus 506. A suitable display device / input 
device 508, such as a keyboard or pointing device in com- 
bination with a monitor, may be provided for receiving 



data from and outputting data to a user of the system. A 
memory 510, which is associated with the rewards server 
502, includes a variety of software modules, such as an 
association module 512, a rewards calculation module 
514, a data analysis module 516, and a filtering module 
518 for example. The memory 510 preferably further in- 
cludes an operating system 520 which enables execution 
by central processor 504 of the various software applica- 
tions residing at the various modules 512, 514, 516, and 
518. Operating system 520 may be any suitable operating 
system, as described above. Preferably, a network inter- 
face 522 is provided for suitably interfacing with other el- 
ements of the incentive awards system, such as the ele- 
ments described above with reference to FIGS. 1-3. 
[0082] Lastly, a storage device 524, such as a database as de- 
scribed above for example, preferably contains files or 
records which are accessed by the various software mod- 
ules 512, 514, 516, and 518. In particular, manufacturer 
data 526 comprises information received from a manufac- 
turer, such as descriptions or other information regarding 
the manufacturer's products and/or services as well as 
UPC data for example. Retailer data 528 comprises infor- 
mation received from a retailer, such as descriptions or 



other information regarding tlie retailer's products and/or 
services as well as SKU data for example. Consumer data 
530 comprises information pertaining to a consumer, in- 
cluding a consumer ID, purchase data, a consumer profile, 
and/or the like. One skilled in the art will appreciate that 
the storage device 524 and, therefore, manufacturer data 
526, retailer data 528, and consumer data 530 may be 
co-located with the rewards server 502 or may be re- 
motely located with respect to the rewards server 502. If 
the storage device 524 is remotely located with respect to 
the rewards server 502, communication between storage 
device 524 and rewards server 502 may be accomplished 
by any suitable communication link but is preferably ac- 
complished through a private intranet or extranet. 

[0083] Referring next to FIGS. 6 and 7, the process flows de- 
picted in these figures are merely exemplary embodi- 
ments of the invention and are not intended to limit the 
scope of the invention as described above. It will be ap- 
preciated that the following description makes appropri- 
ate reference not only to the steps depicted in FIGS. 6 and 
7 but also to the various system components as described 
above with reference to FIGS. 1-3. 

[0084] FIG. 6 is flowchart illustrating an exemplary process for 



capturing and processing POS SKU data in accordance with 
the present invention. The association or matching of UPC 
and SKU data begins with POS data capture (step 602). 
When a consumer presents a consumer ID to a retailer 
104 at the time of purchasing an item from the retailer 
104, the consumer ID is processed by a rewards terminal 
116 that recognizes the consumer ID and identifies the 
consumer as a participant in the system 100. Purchase 
data is captured by the retailer POS terminal 112. Pur- 
chase data may include any of the following: a SKU num- 
ber; a unit price; a total transaction price; the payment ve- 
hicle(s) used; a store ID which identifies the particular 
store location if a retailer operates more than one store; a 
department ID, if the store has multiple departments; the 
date of the transaction; the time of the transaction; the 
employee ID of the store clerk who facilitates the transac- 
tion; a POS terminal ID to identify the particular terminal 
conducting the transaction; any retailer-specific incentive 
program ID; and/or the like. The retailer POS terminal 112 
creates a transaction file comprising the consumer data 
(including a consumer ID) and purchase data (including a 
SKU number associated with each item purchased), and 
the transaction file is then stored by the retailer processor 



110 in database 111 (step 604). 

[0085] The various transaction files may be consolidated by the 
retailer processor 110 and then forwarded to the retailer 
regional processor 114 (step 606) for further back-office 
and cumulative data analysis performed by retailer 104. 

[0086] In an exemplary embodiment, the transaction file is trans- 
mitted by either of the retailer processor 110 or the re- 
tailer regional processor 114 to the rewards server 120 
(step 608). The SKU information for each item included in 
the transaction file is then matched to or associated with 
corresponding UPC information which identifies the re- 
lated manufacturer 106. An exemplary association pro- 
cess is illustrated in the flowchart of FIG. 7. Association of 
SKU and UPC data may be accomplished through any data 
association technique known and practiced in the art. For 
example, the association may be accomplished either 
manually or automatically. Automatic association tech- 
niques may include, for example, a database search, a 
database merge, GREP, AGREP, SQL, and/or the like. 

[0087] In an exemplary embodiment, database 121 receives and 
stores manufacturer data, including UPC data, from man- 
ufacturer 106 (step 702). Database 121 also receives and 
stores retailer data, including SKU numbers, from retailer 



104 (step 704). In an exemplary implementation, database 
121 stores manufacturer data in a separate manufacturer 
data table for each participating manufacturer 106. Each 
manufacturer data table may comprise a plurality of fields, 
such as "UPC" and "product description" for example, and 
a plurality of records, each of which corresponds to an 
item offered by the participating manufacturer 106. In one 
embodiment, database 121 stores retailer data in a sepa- 
rate retailer data table for each participating retailer 104. 
Each retailer data table may comprise a plurality of fields, 
such as "SKU"and "product description", for example, and 
a plurality of records, each record corresponding to an 
item offered by a participating retailer 104. 
[0088] Data from each of the manufacturer and the retailer data 
tables is then associated (step 706). The association step 
may be accomplished by a database merge function, for 
example, using a "key field" in each of the manufacturer 
and retailer data tables. A "key field" partitions the 
database according to the high-level class of objects de- 
fined by the key field. For example, a "product descrip- 
tion" class may be designated as a key field in both the 
manufacturer data table and the retailer data table, and 
the two data tables may then be merged on the basis of 



the "product description" data in tlie l<ey field. In this em- 
bodiment, the data corresponding to the key field in each 
of the merged data tables is preferably the same. That is, 
the product descriptions in the manufacturer data table 
matches the product descriptions in the retailer data ta- 
ble. However, manufacturer and retailer data tables having 
similar, though not identical, data in the key fields may 
also be merged by using AGREP, for example. 
[0089] The result of the data association step is the creation of a 
separate data table, such as a UPC/SKU lookup table for 
example (step 708). Thus, when the rewards server 120 
receives the data (e.g., consumer ID and SKU data) cap- 
tured by the POS terminal (step 710), the rewards server 
120 may search the UPC/SKU lookup table for the appro- 
priate SKU number and then match the SKU to the corre- 
sponding UPC data (step 712). In an exemplary embodi- 
ment, the "SKU" and "UPC" fields in the UPC/SKU data ta- 
ble may be linked by an appropriate pointer. That is, when 
the rewards server 120 searches the UPC/SKU table and 
locates the particular SKU that has been captured and 
transmitted by the POS terminal, the specifically identified 
SKU datafield uses a pointer to direct the rewards server 
120 to the UPC datafield that corresponds to that SKU 



number. In an exemplary embodiment, the UPC datafield 
may be linked by one or more additional pointers to other 
key fields, such as a consumer ID, a retailer ID, a manu- 
facturer ID, and/or a third-party ID. These additional 
pointers may be used as means for compiling data which 
may be useful in any of the various data analyses per- 
formed by the rewards server 120. In this manner, the as- 
sociation of POS SKU numbers and UPC data may be used 
to create a context in which standardized, network-wide 
analyses may be conducted. 
[0090] In an exemplary embodiment, the rewards server 120 uti- 
lizes the association information to calculate the rewards 
points generated by a consumer's purchase. For example, 
an appropriate series of pointers leading from a SKU to a 
UPC to a manufacturer ID may ultimately direct the re- 
wards server 120 to employ a 2-for-l manufacturer re- 
wards ratio to award a consumer twice as many points as 
the dollar amount of the consumer's total transaction 
price. In another exemplary embodiment, an appropriate 
series of pointers may result in the calculation of rewards 
points based upon multiple rewards criteria, such as re- 
wards criteria associated with the manufacturer of the 
item as well as rewards criteria associated with a third- 



party provider for example. 

[0091] In a further embodiment, the rewards server 120 may use 
the association of UPC and SKU number data to analyze a 
variety of marketing variables across multiple manufac- 
turers and retailers. For example, rewards server 120 may 
use a series of pointers leading from an SKU to a UPC and 
then to a "consumer profile" field or table to correlate, for 
instance, consumer spending behaviors, particular manu- 
facturers, and/or specific products across multiple retail- 
ers for example. 

[0092] In alternative embodiments, association of the UPC data 
and SKU number may take place at any of the rewards ter- 
minal 116, the retailer POS terminal 112, the retailer pro- 
cessor 110, the retailer regional processor 114 (or a re- 
tailer national processor), and/or the central rewards 
mechanism 102. 

[0093] In one embodiment, the retailer 104 may offer an incen- 
tive or loyalty program that is independent from the pro- 
gram offered by the system 100. Alternatively, the retailer 
104 may use the system's UPC data for its own internal 
purposes. 

[0094] vvith momentary reference to FIG. 6, in one exemplary 

embodiment, the consumer ID and the earned rewards in- 



formation are transmitted to the central rewards meclia- 
nism 102 after the rewards server 120 has filtered out 
consumer data associated with the consumer ID (step 
610). In another embodiment, the central rewards mecha- 
nism 102 may use the captured and matched UPC infor- 
mation to determine rewards and/or for data analysis. 
[0095] In accordance with another aspect of the invention, FIG. 8 
is an exemplary diagram illustrating an exemplary virtual 
purchasing system 800. Virtual purchasing system 800 
creates a purchasing environment that combines the op- 
portunity to physically inspect the goods that are offered 
for sale by "brick and mortar" retail establishments with 
the automation, convenience, and large selection offered 
by an online retail network. In an exemplary aspect, virtual 
purchasing system 800 facilitates a convenient purchasing 
environment which enables a consumer to select the par- 
ticular goods that they wish to purchase, transmit data re- 
garding the selected goods to a virtual purchaser, and 
then purchase the selected goods under perceived optimal 
conditions through the virtual purchaser. The perceived 
optimal conditions may include conditions such as lowest 
price, quickest estimated delivery time, or a preferred re- 
tailer, for example. 



[0096] In the exemplary embodiment illustrated in FIG. 8, virtual 
purchasing system 800 comprises a consumer terminal 
802, a central rewards mechanism 804, a virtual pur- 
chaser 806, and a retailer/merchant system 808. It will be 
appreciated that the system 800 may comprise any num- 
ber of consumer terminals 802 and any number of retailer 
systems 808. 

[0097] jhe consumer terminal 802 may be any remote terminal 
through which a consumer may access other aspects of 
the system 800. Consumer terminal 802 may comprise 
any of the input devices, computing units, or computing 
systems described above. In an exemplary aspect, con- 
sumer terminal 802 may be implemented in the form of 
an electronic hand-held device or personal digital assis- 
tant, such as a Palm Pilot® available from Palm, Inc. (Santa 
Clara, CA), for example. Consumer terminal 802 commu- 
nicates with the system 800 through any of the communi- 
cations networks described above. In an exemplary as- 
pect, consumer terminal 802 permits wireless communi- 
cation with the system 800. In one embodiment, con- 
sumer terminal 802 may operate in real-time, as de- 
scribed above. In another embodiment, the consumer ter- 
minal 802 may operate in batch mode, as described 



above. In still a further embodiment, consumer terminal 
802 operates in a manner which includes aspects of both 
real-time functionality and batch mode functionality. 

[0098] In an exemplary aspect, consumer terminal 802 permits a 
consumer to engage multiple facets of the system 800 in 
an interactive online communications environment. The 
interactive online environment made available through 
consumer terminal 802 is an extension of the network- 
level system and is implemented in conjunction with other 
aspects of the system 800. In this context, a consumer 
may use consumer terminal 802 for a variety of purposes. 
In another exemplary aspect, consumer terminal 802 is 
adapted to input a retailer item identifier associated with 
an item located at a retailer's store and then communicate 
the retailer item identifier to virtual purchaser 806. In one 
embodiment, consumer terminal 802 comprises an input 
device 810; a network interface 812 which facilitates 
communication with the virtual purchaser 806; and a vir- 
tual purchaser (VP) application module 814. 

[0099] Input device 810 may be any device that is capable of 

identifying a retailer item identifier. Input device 810 may 
be configured to communicate a retailer item identifier to 
consumer terminal 802 in real time or some time later. In- 



put device 810 may be integrated with consumer terminal 
802 or may be a separate component that is adapted to 
communicate with consumer terminal 802. Exemplary in- 
put devices may include devices for manually inputting a 
retailer item identifier (such as an alphanumeric keypad, 
for example) and devices for optically, electronically or 
digitally inputting a retailer item identifier (such as a bar 
code reader or scanner, for example). 

[0100] In an exemplary embodiment, input device 810 includes a 
conventional bar code reader which is adapted to scan a 
retailer item identifier. In one embodiment, the bar code 
reader is integrated with, and is a part of, the consumer 
terminal 802. In this embodiment, the input device 810 is 
used to input a retail item identifier and then communi- 
cate the retail item identifier to consumer terminal 802 
while, or soon after, reading the retail item identifier. In 
another embodiment, the bar code reader is a separate 
component (such as a wand or a pen for example). In this 
embodiment, input device 810 is configured to input and 
then store a retailer item identifier for later communica- 
tion (e.g., downloading) to consumer terminal 802. 

[0101] Network interface 812 may be any suitable interface for 
establishing a communications link between consumer 



terminal 802 and virtual purchaser 806 and may establish 
communication with virtual purchaser 806 by any of the 
communications means set forth in detail above. In one 
embodiment, network interface 812 facilitates wireless 
communication between consumer terminal 802 and vir- 
tual purchaser 806. 

[0102] VP application module 814 is configured to facilitate in- 
teraction between consumer terminal 802 and virtual pur- 
chaser 806. After consumer terminal 802 receives a re- 
tailer item identifier from input device 810, VP application 
module 814 processes, stores, and/or communicates the 
retailer item identifier to virtual purchaser 806 via net- 
work interface 812. 

[0103] The central rewards mechanism 804 is substantially simi- 
lar to, and may comprise any of the components of, cen- 
tral rewards mechanism 102 and/or central rewards 
mechanism 402, as described above with reference to 
FIGS. 1-4. Moreover, central rewards mechanism 804 may 
be configured to include any of the functionality described 
above with reference to central rewards mechanism 102 
and/or central rewards mechanism 402. In particular, 
central rewards mechanism 804 comprises an enrollment 
module 816, which is substantially similar to enrollment 



module 512 of FIG. 5, and a storage device 818, which is 
substantially similar to storage device 420 of FIG. 4. In 
one embodiment, enrollment module 816 receives con- 
sumer enrollment data from consumers and then pro- 
cesses and transmits the consumer enrollment data to 
storage device 818 for storage and future retrieval. 
[0104] In one embodiment, virtual purchaser 806 comprises a 
purchase module 820 and a database 822. As illustrated 
in FIG. 9, an exemplary virtual purchaser 806 further in- 
cludes a processor 824 in communication with other ele- 
ments of virtual purchaser 806 through an interface or 
bus 826. A suitable display/input device 828, such as a 
keyboard or pointing device in combination with a moni- 
tor, may be provided for receiving data from and out- 
putting data to a user of virtual purchaser 806. A memory 
830 associated with virtual purchaser 806 includes a pur- 
chase module 820. Memory 830 further includes an oper- 
ating system 832 which enables execution by processor 
824 of the software applications residing at purchase 
module 820. Operating system 832 may be any suitable 
operating system, as described above. The database 822 
may be any type of database, such as relational, hierarchi- 
cal, object-oriented, and/or the like. Common database 



products that may be used to implement database 822 in- 
clude DB2 by IBM (White Plains, NY), any of the database 
products available from Oracle Corporation (Redwood 
Shores, CA), any of the database products available from 
Sybase, Inc. (Emeryville, CA), Microsoft Access by Mi- 
crosoft Corporation (Redmond, Washington), or any other 
database product. In one embodiment, a network inter- 
face 834 is provided for facilitating the interface of virtual 
purchaser 806 with other elements of the virtual purchas- 
ing system 800, described herein with reference to FIG. 8. 

[0105] In another embodiment, virtual purchaser 806 includes an 
authentication module 821 which facilitates the authenti- 
cation and/or validation of the identity and/or status of 
consumers who seek access to virtual purchaser 806 
through a consumer terminal 802. The authentication 
module 821 may have access to a suitable storage device, 
such as database 822 for example, which maintains 
records identifying authorized consumers. 

[0106] Referring once again to FIG. 8, virtual purchasing system 
800 further includes one or more retailer systems 808. 
The retailer system 808 is substantially similar to, and 
may comprise any of the components of, retailer system 
104, as described above with reference to FIGS. 1, 2, and 



3. Moreover, retailer system 808 may be configured to in- 
clude any of the functionality described above with refer- 
ence to retailer system 104. In an exemplary embodiment, 
the retailer system 808 is in communication with a 
database 809. Database 809 is substantially similar to, 
and may comprise any of the components and/or func- 
tionality of, database 111, as described above. In one em- 
bodiment, database 809 stores retailer item identifiers 
and related data, such as item descriptions and item 
prices for example. 

[0107] The rewards server 836 is substantially similar to, and 

may comprise any of the components and/or functionality 
of, rewards server 120 and/or 502, as described above 
with reference to FIGS. 2, 3, and 5. In an exemplary em- 
bodiment, the rewards server 836 is in communication 
with a database 837. Database 837 is substantially similar 
to, and may comprise any of the components and/or 
functionality of, database 121, as described above. Al- 
though rewards server 836 is depicted in FIG. 8 as a sepa- 
rate component of system 800, in an alternate embodi- 
ment of the invention, the functionality of rewards server 
836 is integrated with virtual purchaser 806. 

[0108] Referring next to FIGS. 10 and 11, the process flows de- 



picted in these figures are merely exemplary embodi- 
ments of the invention and are not intended to limit the 
scope of the invention as described above. It will be ap- 
preciated that the following description makes appropri- 
ate reference not only to the steps depicted in FIGS. 10 
and 11 but also to the various system components as de- 
scribed above with reference to FIGS. 8 and 9. FIG. 10 is 
flowchart illustrating an exemplary process for facilitating 
a search (for example, a network-wide search) for an item 
which corresponds to a given retailer item identifier. Con- 
ducting a network-wide search begins with enrolling a 
consumer in the system of the invention (step 1002). As 
described above, enrollment is accomplished by central 
rewards mechanism 804. That is, enrollment module 816 
receives and processes the consumer enrollment data, fa- 
cilitates issuance of a consumer ID to the consumer, and 
transmits the consumer enrollment data to storage device 
818. After a consumer is enrolled in the system, the con- 
sumer may use the consumer ID when interacting with the 
virtual purchaser 806 and/or during a purchase transac- 
tion facilitated by virtual purchaser 806. 
[0109] After a consumer has enrolled in the system of the inven- 
tion, the consumer uses input device 810 to facilitate the 



capture, scan, read, or otherwise input of a retailer item 
identifier associated with an item located at a retailer 
store into consumer terminal 802 (step 1004). In one em- 
bodiment, the consumer terminal 802 is present at the re- 
tailer store and the retailer item identifier is input directly 
into consumer terminal 802. In another embodiment, in- 
put device 810 stores the retailer item identifier and then 
downloads the data to consumer terminal 802 at a later 
time. After consumer terminal 802 receives the retailer 
item identifier, consumer terminal 802 can facilitate es- 
tablishing communications with virtual purchaser 806. 
10] Once consumer terminal 802 contacts virtual purchaser 
806, consumer terminal 802 facilitates transmission of a 
retailer item identifier to virtual purchaser 806 to facilitate 
a network-wide search for that item corresponding to the 
retailer item identifier (step 1006). In one embodiment, 
contacting virtual purchaser 806 includes using a con- 
sumer ID for identification of the consumer and/or for au- 
thorization to access the virtual purchaser 806. Once con- 
tacted, virtual purchaser 806 may request that the con- 
sumer select search criteria which virtual purchaser 806 
may use to customize a network-wide search for items 
that correspond to the retailer item identifier transmitted 



by consumer terminal 802 (step 1008). In one embodi- 
ment, the requested search criteria may include any num- 
ber of the following: an item description, an item price, a 
quantity of the item, a retailer name or identifier, a retailer 
location that is nearest the consumer, a consumer rating 
of items and/or retailers, lowest price available for the 
item, quickest estimated delivery time, a preferred re- 
tailer, and/or the like. In another embodiment, the con- 
sumer may select a set of master search criteria which are 
stored in database 822 as a default set of search criteria 
which is used by virtual purchaser 806 in subsequent 
searches requested by the consumer, unless in one em- 
bodiment the consumer overrides the master search crite- 
ria during a particular session. In this embodiment, the 
search criteria (i.e., master search criteria) may be se- 
lected and transmitted to the virtual purchaser 806 by the 
consumer prior to transmitting a particular retailer item 
identifier. In one embodiment, selection of consumer 
search criteria and/or master search criteria is facilitated 
by purchase module 820. 
1] In another embodiment, the virtual purchaser 806 may 
permit the consumer to pre-authorize the virtual pur- 
chaser to facilitate automatic purchase of the item on be- 



half of the consumer, if the search results include an item 
which matches the consumer's specified search criteria 
(step 1010). In another embodiment, the virtual purchaser 
806 permits the consumer to select a desired format for 
the search results, such as displaying all search results for 
the consumer or displaying some subset (e.g., retailers 
and/or items that exactly match the consumer's selection 
criteria) of the search results, for example. 

[0112] After virtual purchaser 806 receives the retailer item iden- 
tifier and receives any search criteria from the consumer 
terminal 802 (or accesses any master search criteria), the 
retail item identifier is translated or associated with a 
standard identifier, such as a manufacturer item identifier, 
for example (step 1012). The standard identifier can be 
used to search the network for the same or similar items 
that may be offered for sale by other retailers under dif- 
ferent conditions and/or terms (i.e., conditions and/or 
terms that are perceived to be more favorable by the con- 
sumer, as determined by the search criteria). 

[0113] In one embodiment, the virtual purchaser 806 facilitates 
transmission to the retailer item identifier and any search 
criteria to rewards server 836 to accomplish the associa- 
tion process. In this embodiment, the retailer item identi- 



fier (e.g., a SKU) is standardized to facilitate a searcli (e.g., 
local, with a category, network-wide, etc) for the item 
identified by the SKU. Standardization is accomplished by 
matching or associating the SKU information with a corre- 
sponding manufacturer item identifier (e.g., a UPC) which 
identifies the manufacturer of the item and/or a general 
description of the goods or services. Association of SKU 
and UPC data may be accomplished through any data as- 
sociation technique known and practiced in the art. For 
example, the association may be accomplished either 
manually or automatically. Automatic association tech- 
niques may be facilitated by, for example, a database 
search, a database merge, GREP, ACREP, SQL, and/or the 
like. An exemplary method for associating SKU and UPC 
data is described above with reference to FIG. 7. 
^4] In one embodiment, after associating the retailer item 
identifier with a manufacturer item identifier, rewards 
server 836 then uses the UPC data (target UPC) to facili- 
tate a further search of database 837 (step 1014). This 
second search looks for the target UPC data across partic- 
ipating retailers whose data (e.g., retailer identifier, items 
available, descriptions of items available, item price, de- 
livery information, and the like) is stored in database 837. 



As the rewards server 836 locates retailers associated with 
the target UPC data, rewards server 836 adds the relevant 
retailer identifier data, as well as any retailer data that 
may be relevant to the search criteria, to a retailer file 
(step 1016). If rewards server 836 is unable to sufficiently 
locate a certain number of retailers that are associated 
with the target UPC data (e.g., the item is not carried by 
other participating retailers or the item has been discon- 
tinued and is no longer carried by participating retailers), 
rewards server 836 may search database 837 for the item 
description that is associated with the target UPC data and 
the transmitted SKU. In this manner, rewards server 836 
may locate items that are similar to the item desired by 
the consumer. In an alternate embodiment, depending on 
the search criteria provided by the consumer, rewards 
server 836 may conduct a search for similar items even 
though retailers carrying items associated with the target 
UPC have been located. Once the search is complete, the 
rewards server 836 then transmits the retailer file con- 
taining the retailer data to virtual purchaser 806. In one 
embodiment, virtual purchaser 806 receives and pro- 
cesses the retailer file in accordance with any applicable 
consumer search criteria, any search results formatting 



criteria, and/or any data relating to a pre-autliorized au- 
tomatic purcliase of tlie item (step 1018). 

[0115] After processing the retailer file, the virtual purchaser 806 
enters a purchasing routine (step 1020). An exemplary 
purchasing routine is illustrated in FIG. 11. If the con- 
sumer has pre-authorized an automatic purchase, pur- 
chase module 820 effects the purchase on behalf of the 
consumer, as described in greater detail below. If the con- 
sumer has not pre-authorized an automatic purchase, vir- 
tual purchaser 806 transmits a list of the search results to 
consumer terminal 802 (step 1102). Upon receiving the 
search results, consumer terminal 802 may select a re- 
tailer from which the consumer wishes to purchase the re- 
quested item (step 1104). 

[0116] If the consumer has pre-authorized the automatic pur- 
chase of the item, purchase module 820 facilitates the 
pre-authorized purchase for the consumer. In one em- 
bodiment, purchase module 820 requests transaction card 
information from central rewards mechanism 804 (step 
1106). As described above, storage device 818 contains 
consumer enrollment data which includes transaction card 
information for the consumer. The transaction card infor- 
mation is transmitted from central rewards mechanism 



802 to virtual purchaser 806, and purchase module 820 
uses the transaction card information to complete a pur- 
chase transaction on behalf of the consumer with the re- 
tailer that satisfies the consumer's search criteria (step 
1108). Once the purchase transaction is complete, virtual 
purchaser 806 sends a confirmation to the consumer ter- 
minal 802 indicating that the requested purchase has 
been made (step 1110). The confirmation may be in any 
suitable form, such as through an email, over the phone, 
or through the mail, for example, and may include any 
suitable information, such as information which indicates 
the retailer, the price, the particular item, the quantity, the 
delivery time frame, and/or the like. 
17] If the consumer selects a retailer from which to purchase 
the item after viewing the search results, the purchase 
module 820 queries whether the consumer wishes to use 
the transaction card on file with the central rewards 
mechanism 804 (step 1112). If the consumer wishes to 
use the transaction card that is on file with the system, 
purchase module 820 completes the purchase transaction 
in the manner described above with reference to a pre- 
authorized purchase transaction (steps 1106 through 
1110). If the consumer wishes to use an alternate method 



of payment, the purchase module requests, receives, and 
processes the new payment information (1114). Once the 
new payment information is received, the purchase trans- 
action with the selected retailer is completed (step 1116), 
and confirmation is sent to the consumer as described 
above (step 1118). 
[0118] In an exemplary embodiment, once the confirmation is 

sent to the consumer, the virtual purchaser 806 may also 
send an automatic reminder to the consumer as the deliv- 
ery data approaches. In another embodiment, the virtual 
purchaser 806 may also provide automatic tracking of the 
shipment for the consumer. 

In accordance with another aspect of the invention, FIG. 
12 is a diagram illustrating an exemplary consumer pur- 
chasing analysis system 1200. Consumer purchasing 
analysis system 1200 may be used to analyze a con- 
sumer's purchasing behaviors, compare budgeted pur- 
chases with actual purchases, compare prices of various 
retailers, and generate reports which detail these analyses 
and therefore assist a consumer in managing their per- 
sonal finances. The comprehensive nature of the data 
made available to a consumer through consumer purchas- 
ing analysis system 1200 permits network-wide, product- 



level knowledge of a consumer's specific purchasing pat- 
terns across retailers. The detailed tracking provided by 
consumer purchasing analysis system 1200 of a con- 
sumer's particular purchasing activities permits the con- 
sumer to analyze those activities and thereby achieve 
greater control over their personal financial situation. 

[0120] In the exemplary embodiment illustrated in FIG. 12, con- 
sumer purchasing analysis system 1200 comprises a re- 
tailer/merchant system 1202, a reward server 1204, and a 
consumer system 1206. It will be appreciated that the 
system 1200 may comprise any number of retailer sys- 
tems 1202 and any number of consumer systems 1206. 

[0^21] In an exemplary embodiment, the retailer system 1202 
comprises a retailer terminal 1208, a smart interface 
1209, and a retailer processor 1210. The retailer proces- 
sor 1210 may be in communication with a database 1211. 
The retailer system 1202 is substantially similar to, and 
may comprise any of the components of, retailer system 
104, as described above with reference to FIGS. 1-3. 
Moreover, retailer system 1202 may be configured to in- 
clude any of the functionality described above with refer- 
ence to retailer system 104. Retailer terminal 1208 is sub- 
stantially similar to, and may comprise any of the compo- 



nents and/or functionality of, retailer terminal 108; re- 
tailer processor 1210 is substantially similar to, and may 
comprise any of the components and/or functionality of, 
retailer processor 110; and database 1211 is substantially 
similar to, and may comprise any of the components and/ 
or functionality of, database 111. Smart interface 1209 is 
any device which is configured to interface with input de- 
vice 1216. Exemplary smart interfaces include a smartcard 
reader, an RF reader, and an RF transceiver reader. 

[0122] The rewards server 1204 is substantially similar to, and 

may comprise any of the components and/or functionality 
of, rewards server 120 and/or 502, as described above 
with reference to FIGS. 2, 3, and 5. In an exemplary em- 
bodiment, the rewards server 1204 is in communication 
with a database 1205. Database 1205 is substantially 
similar to, and may comprise any of the components and/ 
or functionality of, database 121, as described above. 

[0123] In an exemplary embodiment, the consumer system 1206 
comprises a consumer terminal 1214 and an input device 
1216. Optionally, consumer system 1206 may also include 
a smart interface 1218. Consumer terminal 1212 may be 
any remote terminal through which a consumer may ac- 
cess other aspects of the system 1200 and may comprise 



any of the input devices, computing units, or computing 
systems described lierein. Furtlier, consumer terminal 
1212 communicates witli the system 1200 through any of 
the communications networl<s described above. In an ex- 
emplary aspect, consumer terminal 1212 comprises a data 
analysis application 1214. Data analysis application 1214 
may be any suitable application for analyzing data. Com- 
mon data analysis products that may be used to imple- 
ment data analysis application 1214 include Quicken® or 
any of the other products available from Intuit, Inc. 
(Mountain View, CA), Microsoft Money® by Microsoft Cor- 
poration (Redmond, Washington), or any other data analy- 
sis product. 

[0124] Smart interface 1218 is any device which is adapted to fa- 
cilitate communication between input device 1216 and 
consumer terminal 1212 if components 1212 and 1216 
are separate devices. Exemplary smart interfaces include a 
smartcard reader, an RF reader, and an RF transceiver 
reader. 

[0125] Input device 1216 may be any device that is capable of re- 
ceiving or uploading purchase data from a retailer system 
1202. Input device 1216 may be configured to communi- 
cate the purchase data to consumer terminal 1212 in real 



time or some time later. Input device 1216 may be inte- 
grated with consumer terminal 1212 or may be a separate 
component that is adapted to communicate with con- 
sumer terminal 1212, such as through smart interface 
1218. Exemplary input devices may include software, 
smartcards and smartcard readers, non-contact smart 
chip systems, read-write transponder systems, and other 
smart chip devices and related technology. In an exem- 
plary aspect, input device 1216 is integrated with a con- 
sumer ID. 

[0126] A number of standards have been developed to address 
general aspects of integrated circuit or smart cards, e.g.: 
ISO 7816-1, Part 1: Physical characteristics (1987); ISO 
7816-2, Part 2: Dimensions and location of the contacts 
(1988); ISO 7816-3, Part 3: Electronic signals and trans- 
mission protocols (1989, Amd.l 1992, Amd. 2 1994); ISO 
7816-4, Part 4: Inter-industry commands for interchange 
(1995); ISO 7816-5, Part 5: Numbering system and regis- 
tration procedure for application identifiers (1994, Amd. 1 
1995); ISO/IEC DIS 7816-6, Inter-industry data elements 
(1995); ISO/IEC WD 7816-7, Part 7: Enhanced inter- 
industry commands (1995); and ISO/IEC WD 7816-8, Part 
8: Inter-industry security architecture (1995). These stan- 



dards are hereby incorporated by reference. Furthermore, 
general information regarding magnetic stripe cards and 
chip cards can be found in a number of standard texts, 
e.g., Zoreda & Oton, "Smart Cards" (1994), and Ranl<l & 
Effing, "Smart Card Handbool<" (1997), the contents of 
which are hereby incorporated by reference. For additional 
information regarding such cards, see, for example, ap- 
plication serial number 09/522,628, filed March 10, 2000, 
entitled "Methods and Apparatus for Authenticating the 
Download of Applets onto a Smartcard," which is hereby 
incorporated by reference. Additionally, for further infor- 
mation on Radio Frequency Identification (RFID) systems 
and their use in the context of read-write transponders, 
see, for example, the recently completed ISO 14443 stan- 
dard, which specifies a standard form of communication 
for non-contact smart chips, and provisional application 
serial number 60/304,216, filed July 10, 2001, entitled 
"System and Method for RFID Payments", the contents of 
which are hereby incorporated by reference. 
[0^2.7] In an exemplary aspect, input device 1216 is a separate 
component of consumer system 1206 that is used to up- 
load purchase data from a retailer system 1202 at the re- 
tailer's location and then download the purchase data to 



consumer terminal 1212 some time later through smart 
interface 1218. In one embodiment, input device 1216 in- 
cludes a smartcard which is adapted to interface with re- 
tailer terminal 1208 through a smart interface 1209 that 
includes a smartcard reader. In another embodiment, in- 
put device 1216 includes a transponder which uses RFID 
to interact with smart interface 1209 without physically 
contacting smart interface 1209. In this embodiment, 
smart interface 1209 includes an RF reader or RF 
transceiver reader. 

[0128] In another exemplary aspect, input device 1216 is inte- 
grated with consumer terminal 1212 and may be used to 
upload purchase data from retailer system 1202 to con- 
sumer terminal 1212 directly. In one embodiment, an in- 
tegrated consumer terminal 1212 and input device 1216 
may communicate with an online retailer system 1202 to 
receive purchase data from the online retailer system 
1202. In another embodiment, consumer terminal 1212 
may be a hand-held electronic device, such as a personal 
digital assistant, which includes an integrated input device 
1216 that is configured to interact with smart interface 
1209 at the retailer's location. 

[0129] Referring next to FIGS. 13 and 14, the process flows de- 



picted in these figures are merely exemplary embodi- 
ments of the invention and are not intended to limit the 
scope of the invention as described above. It will be ap- 
preciated that the following description makes appropri- 
ate reference not only to the steps depicted in FIGS. 13 
and 14 but also to the various system components as de- 
scribed above with reference to FIG. 12. 

[0130] FIG. 13 is flowchart illustrating an exemplary process for 
facilitating obtaining a record of a consumer's purchasing 
activities. Analyzing a consumer's purchasing activities 
may begin when a retailer terminal 1208 processes and 
records a consumer purchase transaction, either online 
(such as at a merchant web site for example) or off-line 
(such as at a retailer store for example) (step 1302). The 
consumer purchase transaction generates purchase data, 
such as any of the purchase data described above. In one 
embodiment, the purchase data may include a retailer 
item identifier, a retailer ID, and an item price. The con- 
sumer system 1206 receives (e.g., uploads) the purchase 
data from retailer system 1202 via input device 1216 (step 
1304). The consumer system then analyzes the purchase 
data using data analysis application 1214 (step 1306). 

[0131] FIG. 14 is a flowchart illustrating an exemplary process for 



analyzing a consumer's purchasing activities. In an exem- 
plary aspect, consumer system 1206 communicates with 
rewards server 1204 to standardize the data used by data 
analysis application 1214. In one embodiment, a con- 
sumer communicates with rewards server 1204 while the 
consumer uses data analysis application 1214 to prepare 
a budget. The consumer accesses rewards server 1204 to 
select the various items that the consumer intends to pur- 
chase over the budget period (step 1402). The budget pe- 
riod may be for any predetermined period of time, such as 
a week, a month, six month, a year, etc. 
[0132] In one embodiment, the rewards server 1204 facilitates 
item selection by designating items by product category 
(e.g., clothes, electronics, sports equipment, etc.) or by 
specific product (e.g., jeans, stereo, bicycle, etc.), includ- 
ing specific products by particular manufacturers. For 
each item selected by the consumer, rewards server 1204 
transmits an appropriate standard identifier to consumer 
terminal 1212 (step 1404). If a consumer designates a se- 
lected item by product category, the rewards server 1204 
transmits a standard identifier that corresponds to a 
product category that is associated with the retailer ID of 
retailers who sell items in that product category. If a con- 



sumer designates a selected item by specific product, tlie 
rewards server 1204 transmits a manufacturer item iden- 
tifier (e.g., UPC) tliat corresponds to that specific product. 
The consumer then completes the budgeting process by 
indicating the amount of funds that the consumer intends 
to spend on each of the selected items (i.e., budgeted 
funds) (step 1406). The data analysis application 1214 
then determines an amount of funds that corresponds to 
the total budget for the budget period (step 1408), and 
the established budget is stored by consumer terminal 
1212 (step 1410). The consumer system 1206 may termi- 
nate the session with the rewards server 1204 any time 
after receiving the appropriate standard identifiers. 
[0133] After the budget is established and stored by consumer 
terminal 1212, the consumer uses input device 1216 to 
transmit purchase data to consumer terminal 1212 (step 
1412). In an exemplary embodiment, after the purchase 
data is transmitted to consumer terminal 1212, consumer 
system 1206 communicates with rewards server 1204 to 
standardize the purchase data (step 1414). Standardiza- 
tion of the purchase data may include facilitating the con- 
version of retailer item identifiers (e.g., SKUs) to manufac- 
turer item identifiers (e.g., UPCs) to facilitate the reconcil- 



iation of actual purchases with the established budget. 
The conversion or association of SKU and UPC data is de- 
scribed above with reference to FIG. 7. After the purchase 
data is standardized and consumer terminal 1212 receives 
the appropriate standard identifiers, the purchase data is 
analyzed by data analysis application 1214. 
[0134] In one aspect of the analysis, budgeted items and actual 
items are correlated with each other based upon the stan- 
dard identifiers (step 1416). That is, a budgeted item that 
is designated by product category is correlated with an 
actual item that is associated with a retailer ID that corre- 
sponds to the appropriate product category. Likewise, a 
budgeted item that is designated by specific product is 
correlated with an actual item that is associated with a 
UPC that corresponds to that specific product. In one em- 
bodiment, the analysis performed by data analysis appli- 
cation 1214 may include a comparison of the established 
budget to actual purchase activity and/or a real-time or 
periodic reconciliation of budgeted items with actually 
purchased items (step 1418). A budget reconciliation may 
include displaying or printing a comparison of budgeted 
items and/or budgeted funds with actually purchased 
items and/or actual funds spent for a selected period 



(e.g., the budget period or any period within the budget 
period). In another embodiment, the analysis may include 
actual or projected cash flow analyses based upon the ac- 
tual funds spent in a given period, for example. 

[0135] In one embodiment, the analysis may include an alert 

when a budget reconciliation determines that over- or un- 
der-spending has occurred, including when over- or un- 
der-spending occurs in specific product categories or for 
specific products (step 1420). In this context, under- 
spending means that budgeted funds have not yet been 
spent. Moreover, the budget reconciliation includes a pre- 
set percentage or amount has been spent or not been 
spent in a category or over a set number of categories. In 
one embodiment, the consumer is alerted by consumer 
terminal 1212. In another embodiment, the consumer 
system 1206 transmits an alert to a third-party, such as a 
financial advisor for example. 

[0136] In general, the invention also includes a system and 

method which facilitates the transfer of all or any portion 
of user income to a user account 20 and user savings ac- 
count 23 based upon a hierarchical based or rules based 
system. The invention also allocates and transfers a por- 
tion of the user income to other accounts (e.g., payee bills 



or debts) based upon other hierarchies and rules, wherein 
the host 5 may transfer a portion of the user income from 
user account 20 to a user savings account 23 ("pay your- 
self) first before paying all or a certain portion of the user 
debts. In one embodiment, the invention includes com- 
plex hardware and software to analyze income sources 
and savings goals before transferring the consumer in- 
come to an automatic bill payment system. As will be ap- 
preciated by one of ordinary skill in the art, the present 
invention may be embodied as a customization of an ex- 
isting system, an add-on product, upgraded software, a 
stand alone system, a distributed system, a method, a 
data processing system, a device for data processing, 
and/or a computer program product. Accordingly, the 
present invention may take the form of an entirely soft- 
ware embodiment, an entirely hardware embodiment, or 
an embodiment combining aspects of both software and 
hardware. Furthermore, the present invention may take 
the form of a computer program product on a computer- 
readable storage medium having computer-readable pro- 
gram code means embodied in the storage medium. Any 
suitable computer-readable storage medium may be uti- 
lized, including hard disks, CD-ROM, optical storage de- 



vices, magnetic storage devices, and/or tlie lilce. 

[0137] The yser income, as used lierein, may include any mone- 
tary or non-monetary income, asset or benefit related to 
the user, wherein the income may be obtained from an in- 
come source of the user (e.g., employer) or any other 
third party. The user income may include paycheck, 
salary, bonuses, commissions, purchase rebate, tax re- 
bates, property, goods, social security, welfare, alimony, 
child support, rental income, securities-related income, 
gambling winnings, credits, loyalty points, reward points, 
coupons, entry passes and/or the like. 

[0138] User debts, as used herein, include any monetary or non- 
monetary liability of the user or any other third party (e.g., 
user may be obligated or desire to pay off the debt of a 
relative, company or associate). The debts may be related 
to bills (e.g., utilities, cable television, phone, etc), car 
payments, loans, mortgages, purchases, voluntary pay- 
ments (e.g., charitable or religious donations), alimony, 
child support, payment plans, lines of credit, financial 
losses, gambling losses, responsibilities and/or the like. 

[0139] An exemplary system 1 according to one embodiment, 
and as set forth in Figure 15, may include one or more 
host 5, user account 20, user savings account 23, user in- 



terface 25, income source 30 and payee 40. The system 
may also include or interface with an automatic bill pay- 
ment system 35. For the sake of brevity, conventional data 
networking, application development and other functional 
aspects of the systems (and components of the individual 
operating components of the systems) may not be de- 
scribed in detail herein. Furthermore, the connecting lines 
shown in the various figures contained herein are in- 
tended to represent exemplary functional relationships 
and/or physical couplings between the various elements. 
It should be noted that many alternative or additional 
functional relationships or physical connections may be 
present in a practical system. 

[0140] Moreover, one skilled in the art will appreciate that, for 

security reasons, any databases, systems, devices, servers 
or other components of the present invention may consist 
of any combination thereof at a single location or at mul- 
tiple locations, wherein each database or system includes 
any of various suitable security features, such as, for ex- 
ample, firewalls, access codes, encryption, decryption, 
compression, decompression, and/or the like. 

[0141] Host 5 may include any hardware and/or software suitably 
configured to facilitate management of user income and/ 



or user income sources. Host 5 may interface, directly or 
indirectly, witli user account 20, user interface 25, income 
sources 30, automatic bill payment system 35, and/or 
payees 40. Host 5 may acquire information, funds or any 
other data from income sources 30 and transfer the funds 
into user account 20. Host may also acquire information 
from payees 40 and/or transfer funds to payees 40 (e.g., 
directly or via automatic bill payment system 35). Host 
may also include debt analyzer 15 and debt database 10. 
Host 5 may also allow the user to track user spending, 
payments and income received. Host 5 may also allow the 
user to import such data from another system or database 
(e.g., security broker database, charge card database), for 
the purpose of helping the user to estimate income, bill 
amounts, the dates when such income will be received or 
when such bills will come due. Host 5 may also allow user 
to utilize user interface 25 to access not only the features 
of system 1, but also personal financial accounting system 
features and information. In this regard, the system may 
also be integrated with any personal financial or account- 
ing system, such as Quicken or any financial advice soft- 
ware. 

[0142] Debt database 10 may include any hardware and/or soft- 



ware suitably configured to facilitate storing debt infor- 
mation. The debt information may include, for example, 
payee account numbers, payee names, bill due dates, 
minimum payment information, penalty information, in- 
terest information, credit rating information, payee rules 
and restrictions, and/or the like. Debt analyzer 15 may in- 
clude any hardware and/or software suitably configured to 
facilitate analysis of the debt information and/or to deter- 
mine a suggested hierarchy of debts. The debt analyzer 
15 may obtain information from a personal financial or 
accounting system in order to provide additional recom- 
mendations which conform at least partially to the sug- 
gestions or restrictions of the financial or accounting 
software. 

[0143] User account 20 may include any hardware and/or soft- 
ware suitably configured to facilitate storing user income 
and/or user income information. The user income infor- 
mation may include, for example, income source data, 
date of deposit or receipt, amounts owed from particular 
income sources, amounts deposited in the user savings 
account 23, dates of deposits in user savings account 23 
and/or the like. 

[0144] User savings account 23 may include any hardware and/or 



software suitably configured to facilitate storing income, 
wherein the income may not have yet been allocated to 
payees 40. User savings account 23 may include, for ex- 
ample, any financial account (e.g., savings, checking, 
money market), loyalty account, security, financial trans- 
action instrument (e.g., stored value card, charge card, 
smart card, transponder), negotiable instrument, coupon 
and/or the like. In an exemplary embodiment, the account 
does not easily allow for withdrawals (i.e., has no check- 
writing privileges, banking or checking card features 
which facilitate easy withdrawals). 

[0145] User interface 25 may include any hardware and/or soft- 
ware suitably configured to facilitate input, receipt and/or 
review of any information related to system 1 or any in- 
formation discussed herein. User interface 25 may include 
any device (e.g., personal computer) which communicates 
(in any manner discussed herein) with host 5 via any net- 
work discussed herein. 

[0146] Automatic bill payment system 35 may include any hard- 
ware and/or software suitably configured to facilitate ac- 
quiring bill information and/or payment of bills. Auto- 
matic bill payment system 35 may include known bill pay- 
ment systems such as, for example, the systems offered 



by Yahoo Bill Pay, Checkfree, PayBllls, PayPal, etc. Auto- 
matic bill payment system 35 may facilitate the payment 
of bills on or near the due date. Because paying some bills 
past the due date may substantially affect the user's credit 
rating, system 1 may incorporate an on-line bill payment 
system 35 to mitigate the late payment risk. Accordingly, 
in one embodiment, the system includes an automatic bill 
payment system 35 or other on-line billing feature that 
allows the user to select bills to be paid on-line and the 
date in which the bills are to be paid. 

[0147] Payees 40 may include one or more person or entity which 
is owed money. Payees 40 may provide or allow access to 
debt information from host 5 directly or via automatic bill 
payment system 35. Payee may also include, for example, 
one or more person, entity, organization, software, hard- 
ware, charity, utility, mortgage company and/or the like. 
Similarly, user may include, for example, one or more 
person, entity, company, charity, organization, software, 
hardware, and/or the like. 

[0148] The various system components discussed herein may in- 
clude one or more of the following: a server or other com- 
puting systems including a processor for processing digi- 
tal data; a memory coupled to said processor for storing 



digital data; an input digitizer coupled to the processor 
for inputting digital data; an application program stored in 
said memory and accessible by said processor for direct- 
ing processing of digital data by said processor; a display 
device coupled to the processor and memory for display- 
ing information derived from digital data processed by 
said processor; and a plurality of databases. Various 
databases used herein may include: user data, debt data, 
income data, merchant data; financial institution data; 
and/or like data useful in the operation of the present in- 
vention. As those skilled in the art will appreciate, user 
computer may include an operating system (e.g., Windows 
NT, 95/98/2000, 0S2, UNIX, Linux, Solaris, MacOS, etc.) 
as well as various conventional support software and 
drivers typically associated with computers, user com- 
puter can be in a home or business environment with ac- 
cess to a network. In an exemplary embodiment, access is 
through a network or the Internet through a commer- 
cially-available web-browser software package. 
[0149] As used herein, the term "network" shall include any elec- 
tronic communications means which incorporates both 
hardware and software components of such. Communica- 
tion among the parties in accordance with the present in- 



vention may be accomplished through any suitable com- 
munication channels, such as, for example, a telephone 
network, an extranet, an intranet, Internet, point of inter- 
action device (point of sale device, personal digital assis- 
tant, cellular phone, kiosk, etc.), online communications, 
off-line communications, wireless communications, 
transponder communications, local area network (LAN), 
wide area network (WAN), networked or linked devices 
and/or the like. Moreover, although the invention is fre- 
quently described herein as being implemented with TCP/ 
IP communications protocols, the invention may also be 
implemented using IPX, Appletalk, IP-6, NetBIOS, OSI or 
any number of existing or future protocols. If the network 
is in the nature of a public network, such as the Internet, 
it may be advantageous to presume the network to be in- 
secure and open to eavesdroppers. Specific information 
related to the protocols, standards, and application soft- 
ware utilized in connection with the Internet is generally 
known to those skilled in the art and, as such, need not be 
detailed herein. See, for example, Dilip Naik, "Internet 
Standards and Protocols" (1998); "Java 2 Complete", vari- 
ous authors, (Sybex 1999); Deborah Ray and Eric Ray, 
"Mastering HTML 4.0" (1997); and Loshin, "TCP/IP Clearly 



Explained" (1997); and David Gourley and Brian Totty, 
"HTTP, The Definitive Guide" (2002), the contents of which 
are hereby incorporated by reference. 

[0150] The various system components may be independently, 
separately or collectively suitably coupled to the network 
via data links which includes, for example, a connection to 
an Internet Service Provider (ISP) over the local loop as is 
typically used in connection with standard modem com- 
munication, cable modem. Dish networks, ISDN, Digital 
Subscriber Line (DSL), or various wireless communication 
methods. See, e.g., Gilbert Held, "Understanding Data 
Communications" (1996), hereby incorporated by refer- 
ence. It is noted that the network may be implemented as 
other types of networks, such as an interactive television 
(ITV) network. Moreover, the system contemplates the 
use, sale or distribution of any goods, services or infor- 
mation over any network having similar functionality de- 
scribed herein. 

[0151] Any databases discussed herein may be any type of 

database, such as relational, hierarchical, graphical, ob- 
ject-oriented, and/or other database configurations. 
Common database products that may be used to imple- 
ment the databases include DB2 by IBM (White Plains, NY), 



various database products available from Oracle Corpora- 
tion (Redwood Shores, CA), Microsoft Access or Microsoft 
SQL Server by Microsoft Corporation (Redmond, Washing- 
ton), or any other suitable database product. Moreover, 
the databases may be organized in any suitable manner, 
for example, as data tables or lookup tables. Each record 
may be a single file, a series of files, a linked series of 
data fields or any other data structure. Association of cer- 
tain data may be accomplished through any desired data 
association technique such as those known or practiced in 
the art. For example, the association may be accom- 
plished either manually or automatically. Automatic asso- 
ciation techniques may include, for example, a database 
search, a database merge, GREP, AGREP, SQL, and/or the 
like. The association step may be accomplished by a 
database merge function, for example, using a "key field" 
in pre-selected databases or data sectors. 
[0152] More particularly, a "key field" partitions the database ac- 
cording to the high-level class of objects defined by the 
key field. For example, certain types of data may be des- 
ignated as a key field in a plurality of related data tables 
and the data tables may then be linked on the basis of the 
type of data in the key field. In this regard, the data corre- 



spending to the key field in each of the linlced data tables 
is preferably the same or of the same type. However, data 
tables having similar, though not identical, data in the key 
fields may also be linked by using AGREP, for example. In 
accordance with one aspect of the present invention, any 
suitable data storage technique may be utilized to store 
data without a standard format. Data sets may be stored 
using any suitable technique, including, for example, 
storing individual files using an ISO/IEC 7816-4 file struc- 
ture; implementing a domain whereby a dedicated file is 
selected that exposes one or more elementary files con- 
taining one or more data sets; using data sets stored in 
individual files using a hierarchical filing system; data sets 
stored as records in a single file (including compression, 
SQL accessible, hashed via one or more keys, numeric, al- 
phabetical by first tuple, etc.); block of binary (BLOB); 
stored as ungrouped data elements encoded using ISO/ 
lEC 7816-6 data elements; stored as ungrouped data ele- 
ments encoded using ISO/IEC Abstract Syntax Notation 
(ASN.l) as in ISO/IEC 8824 and 8825; and/or other pro- 
prietary techniques that may include fractal compression 
methods, image compression methods, etc. 
[0153] In one exemplary embodiment, the ability to store a wide 



variety of information in different formats is facilitated by 
storing the information as a Blocl< of Binary (BLOB). Thus, 
any binary information can be stored in a storage space 
associated with a data set. As discussed above, the binary 
information may be stored on the financial transaction in- 
strument or external to but affiliated with the financial 
transaction instrument. The BLOB method may store data 
sets as ungrouped data elements formatted as a block of 
binary via a fixed memory offset using either fixed stor- 
age allocation, circular queue techniques, or best prac- 
tices with respect to memory management (e.g., paged 
memory, least recently used, etc.). By using BLOB meth- 
ods, the ability to store various data sets that have differ- 
ent formats facilitates the storage of data associated with 
the financial transaction instrument by multiple and unre- 
lated owners of the data sets. For example, a first data set 
which may be stored may be provided by a first issuer, a 
second data set which may be stored may be provided by 
an unrelated second issuer, and yet a third data set which 
may be stored, may be provided by an third issuer unre- 
lated to the first and second issuer. Each of these three 
exemplary data sets may contain different information 
that is stored using different data storage formats and/or 



techniques. Further, each data set may contain subsets of 
data which also may be distinct from other subsets. 
[0154] As stated above, in various embodiments of the present 
invention, the data can be stored without regard to a 
common format. However, in one exemplary embodiment 
of the present invention, the data set (e.g., BLOB) may be 
annotated in a standard manner when provided for ma- 
nipulating the data onto the financial transaction instru- 
ment. The annotation may comprise a short header, 
trailer, or other appropriate indicator related to each data 
set that is configured to convey information useful in 
managing the various data sets. For example, the annota- 
tion may be called a "condition header", "header", "trailer", 
or "status", herein, and may comprise an indication of the 
status of the data set or may include an identifier corre- 
lated to a specific issuer or owner of the data. In one ex- 
ample, the first three bytes of each data set BLOB may be 
configured or configurable to indicate the status of that 
particular data set; e.g., LOADED, INITIALIZED, READY, 
BLOCKED, REMOVABLE, or DELETED. Subsequent bytes of 
data may be used to indicate for example, the identity of 
the issuer, user, transaction/membership account identi- 
fier or the like. Each of these condition annotations are 



further discussed herein. 

[0155] The data set annotation may also be used for other types 
of status information as well as various other purposes. 
For example, the data set annotation may include security 
information establishing access levels. The access levels 
may, for example, be configured to permit only certain in- 
dividuals, levels of employees, companies, or other enti- 
ties to access data sets, or to permit access to specific 
data sets based on the transaction, merchant, issuer, user 
or the like. Furthermore, the security information may re- 
strict/permit only certain actions such as accessing, mod- 
ifying, and/or deleting data sets. In one example, the data 
set annotation indicates that only the data set owner or 
the user are permitted to delete a data set, various identi- 
fied merchants are permitted to access the data set for 
reading, and others are altogether excluded from access- 
ing the data set. However, other access restriction param- 
eters may also be used allowing various entities to access 
a data set with various permission levels as appropriate. 

[0156] The data, including the header or trailer may be received 
by a stand alone interaction device configured to add, 
delete, modify, or augment the data in accordance with 
the header or trailer. As such, in one embodiment, the 



header or trailer is not stored on tlie transaction device 
along with the associated issuer-owned data but instead 
the appropriate action may be taken by providing to the 
transaction instrument user at the stand alone device, the 
appropriate option for the action to be taken. The present 
invention may contemplate a data storage arrangement 
wherein the header or trailer, or header or trailer history, 
of the data is stored on the transaction instrument in rela- 
tion to the appropriate data. 
[0157] The computers discussed herein may provide a suitable 
website or other Internet-based graphical user interface 
which is accessible by users, hosts or operators of the 
system. In one embodiment, the Microsoft Internet Infor- 
mation Server (IIS), Microsoft Transaction Server (MTS), 
and Microsoft SQL Server, are used in conjunction with the 
Microsoft operating system, Microsoft NT web server soft- 
ware, a Microsoft SQL Server database system, and a Mi- 
crosoft Commerce Server. Additionally, components such 
as Access or Microsoft SQL Server, Oracle, Sybase, In- 
formix MySQL, Intervase, etc., may be used to provide an 
Active Data Object (ADO) compliant database manage- 
ment system. 

[0158] Any of the communications, inputs, storage, databases or 



displays discussed lierein may be facilitated through a 
website having web pages. The term "web page" as it is 
used herein is not meant to limit the type of documents 
and applications that might be used to interact with the 
user. For example, a typical website might include, in ad- 
dition to standard HTML documents, various forms, Java 
applets, JavaScript, active server pages (ASP), common 
gateway interface scripts (CGI), extensible markup lan- 
guage (XML), dynamic HTML, cascading style sheets (CSS), 
helper applications, plug-ins, and the like. A server may 
include a web service which receives a request from a web 
server, the request including a URL 
(http://yahoo.com/stockquotes/ge) and an IP address 
(123.56.789). The web server retrieves the appropriate 
web pages and sends the data or applications for the web 
pages to the IP address. Web services are applications 
which are capable of interacting with other applications 
over a communications means, such as the internet. Web 
services are typically based on standards or protocols 
such as XML, SOAP, WSDL and UDDI. Web services meth- 
ods are well known in the art, and are covered in many 
standard texts. See, e.g., Alex Nghiem, "IT Web Services: A 
Roadmap for the Enterprise" (2003), hereby incorporated 



herein by reference. 
[0159] The present invention may be described lierein in terms of 
functional blocl< components, screen shots, optional se- 
lections and various processing steps. It should be appre- 
ciated that such functional blocks may be realized by any 
number of hardware and/or software components config- 
ured to perform the specified functions. For example, the 
present invention may employ various integrated circuit 
components, e.g., memory elements, processing ele- 
ments, logic elements, look-up tables, and the like, which 
may carry out a variety of functions under the control of 
one or more microprocessors or other control devices. 
Similarly, the software elements of the present invention 
may be implemented with any programming or scripting 
language such as C, C++, Java, COBOL, assembler, PERL, 
Visual Basic, SQL Stored Procedures, extensible markup 
language (XML), with the various algorithms being imple- 
mented with any combination of data structures, objects, 
processes, routines or other programming elements. Fur- 
ther, it should be noted that the present invention may 
employ any number of conventional techniques for data 
transmission, signaling, data processing, network control, 
and the like. Still further, the invention could be used to 



detect or prevent security issues with a client-side script- 
ing language, such as JavaScript, VBScript or the like. For a 
basic introduction of cryptography and network security, 
the following may be helpful references: (1) "Applied 
Cryptography: Protocols, Algorithms, And Source Code In 
C", by Bruce Schneier, published by John Wiley & Sons 
(second edition, 1996); (2) "Java Cryptography", by 
Jonathan Knudson, published by O'Reilly & Associates 
(1998); (3) "Cryptography & Network Security: Principles & 
Practice", by William Stalling, published by Prentice Hall; 
all of which are hereby incorporated by reference. 
[0160] Each user, income source, host, payee or other participant 
is equipped with a computing device in order to interact 
with the system and facilitate online commerce transac- 
tions. The customer has a computing unit in the form of a 
personal computer, although other types of computing 
units may be used including laptops, notebooks, hand 
held computers, set-top boxes, cellular telephones, 
touch-tone telephones and the like. The merchant has a 
computing unit implemented in the form of a computer- 
server, although other implementations are contemplated 
by the invention. The bank has a computing center shown 
as a main frame computer. However, the bank computing 



center may be implemented in other forms, such as a 
mini-computer, a PC server, a networl< of computers lo- 
cated in the same of different geographic locations, or the 
like. Moreover, the system contemplates the use, sale or 
distribution of any goods, services or information over any 
network having similar functionality described herein. 

[0161] jhe computers may be interconnected via a second net- 
work, referred to as a payment network. The payment 
network which may be part of certain transactions repre- 
sents existing proprietary networks that presently accom- 
modate transactions for credit cards, debit cards, and 
other types of financial/banking cards. The payment net- 
work is a closed network that is assumed to be secure 
from eavesdroppers. Exemplary transaction networks may 
include the American Express®, VisaNet® and the Veri- 
phone® networks. 

[0162] An "account" or "account number", as used herein, may 
include any device, code, number, letter, symbol, digital 
certificate, smart chip, digital signal, analog signal, bio- 
metric or other identifier/indicia suitably configured to al- 
low the user to access, interact with or communicate with 
the system such as, for example, one or more of an au- 
thorization/access code, personal identification number 



(PIN), Internet code, other identification code, and/or the 
like which may optionally be located on or associated with 
a rewards card, charge card, credit card, debit card, pre- 
paid card, telephone card, smart card, magnetic stripe 
card, bar code card, transponder, radio frequency card or 
an associated account. The account number may be dis- 
tributed and stored in any form of plastic, electronic, 
magnetic, radio frequency, wireless, audio and/or optical 
device capable of transmitting or downloading data from 
itself to a second device. A customer account number may 
be, for example, a sixteen-digit credit card number, al- 
though each credit provider has its own numbering sys- 
tem, such as the fifteen-digit numbering system used by 
American Express. Each company's credit card numbers 
comply with that company's standardized format such 
that the company using a sixteen-digit format will gener- 
ally use four spaced sets of numbers, as represented by 
the number "0000 0000 0000 0000". The first five to 
seven digits are reserved for processing purposes and 
identify the issuing bank, card type, etc. In this example, 
the last (sixteenth) digit is used as a sum check for the 
sixteen-digit number. The intermediary eight-to-ten dig- 
its are used to uniquely identify the customer. A merchant 



account number may be, for example, any number or al- 
pha-numeric characters that identifies a particular mer- 
chant for purposes of card acceptance, account reconcili- 
ation, reporting, or the like. 

[0163] The invention is described herein with reference to screen 
shots, block diagrams and flowchart illustrations of meth- 
ods, apparatus (e.g., systems), and computer program 
products according to various aspects of the invention. It 
will be understood that each functional block of the block 
diagrams and the flowchart illustrations, and combina- 
tions of functional blocks in the block diagrams and 
flowchart illustrations, respectively, can be implemented 
by computer program instructions. These computer pro- 
gram instructions may be loaded onto a general purpose 
computer, special purpose computer, or other pro- 
grammable data processing apparatus to produce a ma- 
chine, such that the instructions which execute on the 
computer or other programmable data processing appa- 
ratus create means for implementing the functions speci- 
fied in the flowchart block or blocks. 

[0164] These computer program instructions may also be stored 
in a computer-readable memory that can direct a com- 
puter or other programmable data processing apparatus 



to function in a particular manner, such that the instruc- 
tions stored in the computer-readable memory produce 
an article of manufacture including instruction means 
which implement the function specified in the flowchart 
block or blocks. The computer program instructions may 
also be loaded onto a computer or other programmable 
data processing apparatus to cause a series of operational 
steps to be performed on the computer or other pro- 
grammable apparatus to produce a computer-imple- 
mented process such that the instructions which execute 
on the computer or other programmable apparatus pro- 
vide steps for implementing the functions specified in the 
flowchart block or blocks. 
[0165] Accordingly, functional blocks of the block diagrams and 
flowchart illustrations support combinations of means for 
performing the specified functions, combinations of steps 
for performing the specified functions, and program in- 
struction means for performing the specified functions. It 
will also be understood that each functional block of the 
block diagrams and flowchart illustrations, and combina- 
tions of functional blocks in the block diagrams and 
flowchart illustrations, can be implemented by either spe- 
cial purpose hardware-based computer systems which 



perform the specified functions or steps, or suitable com- 
binations of special purpose liardware and computer in- 
structions. 

[0166] In one embodiment, tlie foregoing exemplary system may 
be used in the present invention to perform the following 
method. The exemplary method may include, as set forth 
in Figure 16, a registration phase (step 200), a recom- 
mendation phase (step 205), a goal establishment phase 
(step 210), an overdraw analysis phase (step 215) and a 
payment phase (step 220). 

[0167] The registration phase (step 200) may include a user pro- 
viding and system receiving financial information. The 
user may provide the information via any network or com- 
munication system discussed herein. In one embodiment, 
host 5 provides a web page within a website which is 
hosted at a server, wherein the webpage facilitates ob- 
taining personal financial information from the user by, 
for example, menu driven interactive procedures. The user 
may use user interface 25 to enter into a web page the re- 
quested financial information, wherein the financial infor- 
mation may include, for example, user income informa- 
tion, user income source information, user goal informa- 
tion, and user debt information. 



[0168] jhe user income source information may include any in- 
formation related to user income such as, for example, 
income source demographic data, income source routing 
data (e.g., to facilitate the funds being deposited within 
user account 20), amount of income during a particular 
timeframe (e.g., bi-monthly), bonus information (e.g., 
amount and time of year received), tax refund informa- 
tion, estimated commission information and/or the like. 
As set forth above, the user income may include any mon- 
etary or non-monetary income, asset or benefit related to 
the user, wherein the income may be obtained from an in- 
come source of the user (e.g., employer) or any other 
third party. The user income may include paycheck, 
salary, bonuses, commissions, purchase rebate, tax re- 
bates, property, goods, social security, welfare, alimony, 
child support, rental income, securities-related income, 
gambling winnings, credits, loyalty points, reward points, 
coupons and/or the like. The user may also be requested 
to identify the days of the month in which such user in- 
come is received and the amounts of such income. If the 
user receives any or all income at random times (i.e. "not 
periodically"), then the user may estimate the amounts of 
such non-periodic income and indicate when such non- 



periodic income will be received. Host 5 may store the 
user income and user income source information in user 
account database 20. 
[0169] The user income may also include additional funds sub- 
mitted by the user or any other third party to system 1 in 
order to supplement user account 20 or user savings ac- 
count 23. For example, the user may submit extra funds 
with a bill payment such as a single check or money 
transfer for both host charge card purchases and for de- 
posit of money into user savings account 23. When the 
user payment is received by the host or charge card ad- 
ministrator, the payment processing system determines, 
based on the user goals, how each of the user's payments 
should be allocated between charge card payments and 
user savings account 23, namely through the use of a 
payment hierarchy which includes a predetermined set of 
allocation rules. The host or charge card administrator's 
payment processing system may then electronically for- 
ward the appropriate savings amount to user saving ac- 
count 23 based upon another payment hierarchy related 
to the allocation of savings funds among savings, debts or 
investment products. For additional information related to 
submitting additional funds to the system, see for exam- 



pie, U.S. Serial No. 09/415,632 filed on October 12, 1999, 
by inventors Crane, et al., and entitled "SYSTEM AND 
METHOD FOR DIVIDING A REMITTANCE AND DISTRIBUTING 
A PORTION OF THE FUNDS TO MULTIPLE INVESTMENT 
PRODUCTS", which is hereby incorporated by reference. 
[0170] The user goal information may include the amounts the 
user desires to pay himself, any other financial amount, 
limit, milestone, threshold, objective, aspiration and/or 
the like. For example, an amount of money needed for a 
vacation, a major purchase (e.g., house or car), holiday 
gifts, education, or retirement. The amount may be a one- 
time total amount, a pre-established amount for a limited 
time period or continuing time period, or a periodic 
amount which may result in a total savings by a certain 
date (e.g., $10,000 by June 15 of the following year for 
his daughter's wedding). The goal may also include a 
common goal for a group of people such as, for example, 
a group vacation, annual family function, charitable event 
or fundraiser and/or the like. The user goal may be en- 
tered by the user, randomly generated, based on a in- 
creasing or decreasing amount, created using a formula, 
selected by system 1 and/or selected by a third party 
(e.g., parent, financial advisor, etc). The system 1 may 



store the user goal information in user account database 
20. The user may use the goal information for his own 
savings activities or the user may be provided the option 
to set up user savings account 23, wherein the system al- 
locates a portion of the user income to user savings ac- 
count 23. Because many individuals often think of saving 
money based on how much they will have after paying 
bills, the invention attempts to overcome this attitude, in 
an exemplary embodiment, by prompting the user for the 
user goal information before entering user debt informa- 
tion, so that the user is aggressive in the effort to pay 
himself first. Similarly, the user is prompted to enter the 
user goal information before entering income amounts, so 
that the user will be aggressive in setting the user goal in- 
formation. 

[0171] The user debt information includes any information re- 
lated to user debts such as, for example, bills, name and 
address of payees 40, payee account routing information, 
amount of bills, minimum amounts due, due date, peri- 
odic payment plan information and/or the like. As set 
forth above, user debts may include any monetary or non- 
monetary liability of the user or any other third party. The 
debts may be related to bills, car payments, loans, mort- 



gages, purchases, voluntary payments, alimony, child 
support, payment plans, lines of credit, financial losses, 
gambling losses, responsibilities and/or the like. The user 
debts may also include any amount that the user regularly 
pays as part of his living expenses and any other amounts 
that the user pays from time to time, or expects to pay. 
Host 5 may store the user debt information in debt 
database 10. Some bills of course are paid on a regular, 
periodic basis (monthly) and have predetermined amounts 
(e.g. a monthly auto payment of $300; a quarterly insur- 
ance payment of $200.00). Other bills arrive more ran- 
domly and/or in non-fixed amounts, but the bills may be 
anticipated with reasonable accuracy (e.g. health ex- 
penses, tax payments, auto and home maintenance, or 
unexpected events). For both periodic and non-periodic 
bills, the user may enter the day, the month and the due 
date which is the day he expects such bills to become 
due. The due date should not to be confused with the 
date the bill is received, because the due date represents 
the last possible day for bills to be paid. 
[0172] The recommendation phase (step 205) may include, in 

one embodiment, debt analyzer 15 of system 1 reviewing 
the user debt information in debt database 10 to provide 



recommendations related to the prioritization or liierarcliy 
for paying certain bills, the amount to pay for each bill 
and the user goal based upon, for example, user goal in- 
formation, user debt information (e.g., minimum amounts 
due, due dates) and available user income. An exemplary 
embodiment includes periodic income (e.g., employment 
income) because it is often the easiest to base savings 
goals upon periodic income. For example, if the user is 
paid (after deductions) $500.00 a week from an employer, 
then the system 1 may suggest that the user pay himself 
some portion of that $500.00 (e.g., $100.00) before pay- 
ing any bills. In another embodiment, the system may also 
incorporate randomly received income (e.g., a user may 
pay first to himself 10% of any tax refund or other non- 
routine income). 
[0173] In addition to savings suggestions, the system may pro- 
vide the user with recommendations for prioritizing pay- 
ment of bills so that the user may determine when and 
how much to pay himself. For example, the system may 
recommend prioritizing bills to be paid in the following 
order from highest priority to lowest priority: (i) Bills that 
are for essentials (e.g., food, transportation to work and 
school, necessary job-related expenditures, necessary ed- 



ucation-related expenditures); (ii) Bills that affect credit 
rating the most; (iii) Bills that have high penalties for late 
payments; and, (iv) Bills that are for non-essentials. The 
system may also provide recommendations for partial 
payments of bills, where the recommendations are directly 
related to helping the user meet the user goal. For exam- 
ple, if a user has an income of $500.00, and the user 
wants to save $400.00, but the user has a credit card bill 
with a minimum due of $50.00 and a total balance of 
$500.00, the program may recommend that the user sub- 
mits a payment that allows the user to meet his user goal, 
while avoiding a large penalty (e.g., do not pay less than 
the minimum due, but not any larger amount). 
[0174] In further embodiments, the system 1 may allow the user 
to select a passive "recommendation" mode or an active 
"automatic mode". In the passive recommendation mode, 
the debt analyzer 15 provides recommendations to the 
user such as, for example, the amounts to pay himself, 
when the payments to the user savings account 23 will be 
made, the order in which bills should be paid and the 
amounts to be paid toward the bills. In the automatic 
mode, the debt analyzer 15 provides recommendations to 
the user initially, but upon the user accepting or revising 



the recommendations, the system 1 automatically trans- 
fers the payment to the user savings account 23 and to 
the payment of bills. A partial automatic mode may also 
allow the user to choose actions to take place automati- 
cally, while other actions may require approval by the user 
after a recommendation is made by the program. For ex- 
ample, in the partial automatic mode, the user may allow 
the program to automatically direct a payment to the user 
savings account 23, while requiring the system to provide 
a recommendation and waiting for user approval before 
paying certain bills. 
[0175] In another embodiment, the debt analyzer 15 may recom- 
mend that the user pay himself first, but only after funds 
become available in user account 20. In another embodi- 
ment, the system, on a certain date and/or upon a certain 
level of user income being transferred to user account 20, 
automatically transfers a payment from user account 20 to 
the user savings account 23. The system may also allow 
the user to set his own payment criteria (in addition to 
pre-established options) or override the order in which 
debt analyzer recommends that certain bills are to be 
paid. For example, the system may determine that bills for 
essentials (e.g., transportation) are given priority over bills 



that affect credit rating. Tlie user, however, may deter- 
mine that bills that affect his credit rating are more im- 
portant than bills for transportation to work. If the user 
determines that he can walk to work instead of driving or 
using a mass mode of transportation, then the user may 
choose to provide bills that affect credit rating priority 
over such transportation bills. Thus, the system, based 
upon the user's criteria or override, may recommend pay- 
ing bills in an order that gives priority to bills that affect 
credit rating over transportation bills. The system may 
also "learn" the user's preferences over time by analyzing 
the user's inputs and override suggestions such that debt 
analyzer 15 may provide recommendations that more ap- 
propriately conform to more common user inputs and 
override requests. 
[0176] In another embodiment, system 1 may help the user de- 
termine if a goal is possible or realistic within a particular 
timeframe. For example, if the user wants to save $10,000 
in one year to obtain a new car, the system (possibly in 
conjunction with financial management software) may an- 
alyze the user's income sources 30 and provide the rec- 
ommendation that the user should change the goal com- 
pletion date to two years or the user should obtain addi- 



tional income sources. In this manner, the user is more 
likely to reach certain goals and continue to utilize system 
1. Similarly, the system may help the user not only set 
current goals, but also to determine future goal amounts. 
For example, a user may set a goal during the current year 
to buy a new sports car, but in future years, the user's 
child may need to attend college or get married, so the 
user's savings goal may need to increase. As such, system 
1 may calculate the amount of savings needed over vari- 
ous years to meet the current and future goals, wherein 
the savings may be calculated as an equal amount over 
the years or the savings may be calculated as an increas- 
ing amount to correspond to projected increased income 
over the years. 

[0177] In an exemplary embodiment, the system may also pro- 
vide probability modeling which facilitates financial advis- 
ing and planning. A portfolio integration module may fa- 
cilitate integration of at least one of a user's goals, assets, 
savings, and risk tolerance in analyzing and developing a 
customized strategy for financial planning of the user. A 
portfolio reconciler module may communicate with the 
portfolio integration module to facilitate comparison of 
the customized strategy to other strategies and projected 



financial decisions in order to further facilitate the user 
meeting the user goals. A stochastic modeling module in 
communication with the portfolio integration module and 
the portfolio reconciler module may use data from the 
portfolio integration module and/or the portfolio recon- 
ciler module in a stochastic modeling analysis to facilitate 
creation of a proposed situation portfolio for the user. The 
stochastic modeling module may use a synchronous sta- 
tionary bootstrap method of statistical sampling to facili- 
tate analysis of historical economic data in order to facili- 
tate creation of the proposed situation portfolio. A simu- 
lator module in communication with the portfolio integra- 
tion module and the stochastic modeling module may 
forecast the effects of changes to the probability modeling 
system and to monitor and test the system over a prede- 
termined amount of time. For additional information re- 
lated to financial management systems and methods, see 
for example, U.S. Patent No. 5,819,263, issued on October 
6, 1998, by inventors Bromley, et al., and entitled "FINAN- 
CIAL PLANNING SYSTEM INCORPORATING RELATIONSHIP 
AND GROUP MANAGEMENT"; U.S. Patent No. 6,430,542 is- 
sued on August 6, 2002, and entitled "COMPUTER-IM- 
PLEMENTED PROGRAM FOR FINANCIAL PLANNING AND 



ADVISE SYSTEM"; U.S. Serial No. 10/210,827 entitled "SYS- 
TEM AND METHOD FOR FINANCIAL PLANNING AND AD- 
VICE", which was filed on July 13, 2002; and, U.S. Serial 
No. 09/712,743, entitled "SYSTEM AND METHOD FOR 
CREATING FINANCIAL ADVISE APPLICATIONS", filed 
November 14, 2000, all of which are hereby incorporated 
by reference. 

[0178] The goal establishment phase (step 210) may include the 
system and/or the user determining a payment hierarchy 
which may include transferring funds to the user's savings 
account 23 prior to paying all or a portion of certain bills. 
In this regard, the user determines "when" to pay himself 
based on the suggested recommendations and ranking. 
Using the example hierarchy above, one user may choose 
to transfer funds to user savings account 23 after paying 
bills that affect credit rating, but before bills with high 
penalties for late payment. However, another user may re- 
ceive a similar recommended hierarchy list and request 
that the system transfer funds to user savings account 23 
before paying bills in any of the categories set forth in the 
hierarchy listing. 

[0179] The system may also not only pay (or encourage the user 
to pay) the user first (or in a priority position), but the 



system may transfer funds to the user savings account 23 
first in tlie largest amounts possible. For example, if the 
user receives an electric bill on the fifteenth of the month 
that is not due until the first of the next month, the sys- 
tem may prompt the user for the due date and the system 
may recommend that the user to pay the bill on the due 
date and not before the due date. Additionally, if the user 
gets paid on the fifteenth of the month, the system rec- 
ommends that the user pay himself first, leaving enough 
money to pay bills later, including the electric bill that is 
due on the first of the month. After the user pays himself, 
he can also budget discretionary money for entertainment 
purposes, dining out, etc. A responsible user is not likely 
to exceed his budget for discretionary money when he 
knows that bills are due that must be paid. Moreover, if 
the user exceeds the discretionary amount and cannot pay 
bills, then the user has already at least paid the most im- 
portant entity first, namely himself. 
[0180] In order for the user to meet a particular savings goal 

while the user continues to spend money, the system may 
be configured to transfer a certain amount of any user 
transaction amount to user savings account 23. In one 
embodiment, the user or system may set a particular dol- 



lar amount, percentage of purchase amount, number of 
transactions, total dollar amount spent or any other por- 
tion which is calculated based upon user transactions or 
the transaction amounts. For example, the system may 
obtain data from the user's transaction instrument ac- 
count such that every time the user purchases an item 
which costs over $100, the system may transfer $5 of the 
user's income from user account 20 to the user savings 
account 23. In another example, the system may transfer 
S% of the total value of all purchases during the next five 
months to user savings account 23. In these embodi- 
ments, the more a user spends on purchases, the more 
the user may save. Similarly, the system may analyze loy- 
alty point accumulation and transfer loyalty points to a 
savings account based upon a pre-determined formula. 
[0181] vvith respect to loyalty points, the system may incorporate 
loyalty points into any part of the process and provide the 
loyalty points to one or more participants in the process 
(e.g., user, payee, income source). As used herein, loyalty 
points may include any incentive which may or may not 
include points such as, for example, coupons, rewards, 
preferential services, preferential rates, prizes, vacations, 
entertainment packages and/or the like. In one embodi- 



ment, the system may provide loyalty points for every dol- 
lar that the user saves in savings account 23. The system 
may also encourage savings and discourage full payment 
of bills by providing loyalty points for not paying the full 
amount of a bill. The system may also provide a larger 
amount of loyalty points upon reaching a goal or upon 
reaching certain milestones toward the goal. The system 
may also provide extra loyalty points if the user allows the 
system to automatically transfer funds to savings account 
23 without the user's prior approval. If user is utilizing the 
savings account to save money for a future gift or to pro- 
vide a future donation to a charity, the system may allow 
the user to use loyalty points to pay for any portion of the 
gift or to supplement the charitable donation. The system 
may also acquire information related to user loyalty points 
(e.g., from system 1 (wherein the points were earned in 
system 1) or from a third party loyalty system), convert 
the loyalty points to a currency value and apply the cur- 
rency value to user savings account 23 or payees 40 (e.g., 
user debts). 

[0182] In still another embodiment, a government entity, an affil- 
iate or sponsoring entity may provide loyalty points, pre- 
ferred rates or rewards for increased savings. For exam- 



pie, user savings account 23 may be maintained at a banic 
such that the banic may desire to also encourage in- 
creased savings. In this regard, the bank may provide the 
user with loyalty points, higher interest rates, or prizes 
based upon the number of transfers or dollar amount of 
each transfer to the user savings account 23, the total 
amount in user savings account 23 during a certain time 
period and/or the like. For additional information related 
to loyalty systems, see for example, U.S. Serial No. 
10/010,947 entitled "SYSTEM AND METHOD FOR NET- 
WORKED LOYALTY PROGRAM", which was filed on Novem- 
ber 6, 2001; and U.S. Serial No. 09/834,478 entitled "A 
SYSTEM AND METHOD FOR USING LOYALTY POINTS", 
which was filed on April 13, 2001, which are hereby in- 
corporated by reference. 
[0183] While the present invention may be described as transfer- 
ring funds to user savings account 23 first before other 
user debts, the invention also contemplates transferring 
funds to the user savings account 23 at any pre- 
determined time, interval or random period and the in- 
vention also contemplates transferring funds to the user 
savings account 23 before, during or after paying certain 
debts. For example, the system may allow the user to 



identify bills that are to be paid before the system trans- 
fers funds to the user savings account 23 and to identify 
bills to paid after the system transfers funds to the user 
savings account 23. The invention may also include ex- 
ceptions to self payment first which may be determined by 
the user, a government entity or any other entity or per- 
son. The exceptions may include, for example, child sup- 
port must always be paid first, then the user may decide 
on other "first" payment options. The invention may also 
allow the user to identify a priority for bills to be paid 
and/or any predetermined amount or percentage of each 
bill to pay. 

[0184] During the overdraw analysis phase (step 215), prior to 

transferring the user income, host 5 may analyze the bal- 
ance of funds in the user account 20 to determine if suffi- 
cient funds exist for paying the user savings account 23 
and the bills according to the selected payment hierarchy. 
In one embodiment, because bills may vary from month to 
month, as the user enters bills to be paid, the program 
(e.g., in real-time) automatically performs a calculation to 
determine if the bills can be paid without overdrawing or 
exceeding the balance in the user account 20. If insuffi- 
cient funds exist, system 1 may notify the user to readjust 



the payment hierarchy or the system may automatically 
adjust the payment hierarchy based upon pre-established 
rules. The system may notify the user of any overdraw is- 
sues via any communication system or network discussed 
herein. 

[0185] During payment phase (step 220), if sufficient funds exist, 
system 1 transfers a predetermined amount of funds from 
user account 20 to user savings account 23, then to pay- 
ees 40. In one embodiment, host 5 may transfer funds 
and/or payee information to automatic bill payment sys- 
tem 35 such that automatic bill payment system 35 allo- 
cates funds pursuant to pre-existing rules or auto bill pay 
procedures. Host 5 may provide instructions to automatic 
bill payment system 35 in such a way that automatic bill 
payment system 35 allocates consumer income to payees 
40 according to the established hierarchy. For example, 
host 5 may provide automatic bill payment system 35 with 
the approval for payment of a bill for a necessity, then 
host 5 may wait until user savings account 23 reaches a 
pre-established level before providing another payment 
instruction to automatic bill payment system 35. In an- 
other embodiment, automatic bill payment system 35 may 
accept hierarchy or other instructions from system 1 and 



automatically allocate payments according to the hierar- 
chy. 

[0186] Transferring funds, or any similar phrase used herein, 
may include transferring all or any portion of funds, di- 
rectly or indirectly, in any manner (e.g., electronic trans- 
fer, wire, etc). In one embodiment, the "transfer" may in- 
clude, for example, encouraging the user to transfer 
funds, encouraging the user to select a particular transfer 
of funds by the system, providing a negotiable instrument 
(e.g., check) to the user (or to a selected person or entity), 
transferring funds to a charity or other entity (or dividing 
the funds between multiple charities), withdrawing funds 
from one account and depositing funds in another ac- 
count, providing cash, transferring funds to any financial 
instrument discussed herein or known in the art (e.g., ac- 
count, account number, stored value card, gift card, 
charge card credit, etc), sending the financial instrument 
to the user at predetermined intervals (e.g., monthly or 
when the account reaches a pre-determined amount), 
placing the selected funds in a pooled account with other 
family members (e.g., to save for a home improvement 
project), placing the selected funds in a pooled account 
with other friends (e.g., to save for a group vacation). 



and/or the like. The invention contemplates automatically 
receiving user income from income sources 30, automati- 
cally transferring funds to user and/or user savings ac- 
count 23 and automatically transferring funds to payees 
40; however, the invention also contemplates providing 
recommendations to user and allowing the user to obtain 
information, send information, or transfer the user's own 
funds manually or via a third party system. 

[0187] The funds may be transferred periodically to user savings 
account 23, and in an exemplary embodiment, the user 
income may be periodically donated to a charity. For more 
information and details related to periodic transfers, do- 
nation systems and methods, see for example, U.S. Serial 
No. 10/707,715 filed on January 6, 2004, by inventors 
Aviles, et al., and entitled "Donation System and Method", 
which is hereby incorporated by reference. 

[0188] In another embodiment, a stored value or gift card may be 
used to assist in the budgeting process and to meet the 
user goal. For example, the user may obtain an American 
Express Travel Funds Card that is automatically loaded by 
the system with the funds that user needs to pay bills. In 
an exemplary embodiment, the funds desired to meet the 
user's goal are first sent to a user savings account 23. Af- 



ter the user "pays himself and the system receives the 
funds in the user savings account 23, the system may 
then take steps (or allow the user to take steps) to load or 
re-load the stored value card (i.e. the TravelFunds card). 
[0189] Benefits, other advantages, and solutions to problems 
have been described herein with regard to specific em- 
bodiments. However, the benefits, advantages, solutions 
to problems, and any element(s) that may cause any ben- 
efit, advantage, or solution to occur or become more pro- 
nounced are not to be construed as critical, required, or 
essential features or elements of any or all the claims or 
the invention. Further, no element described herein is re- 
quired for the practice of the invention unless expressly 
described as "essential" or "critical". 



